Printable View
Hi,
I have an app that uses both .mdf and .mdb files... this app has not been able to run on Vista and just now going in and changing the setup installer.
We have moved the .mdf and .mdb files out of Program Files and changed our software code to point to new locations in ProgramData (is that the correct place?)
Regardless when we run on Vista it still gives an error that the app cannot write to it.
I searched the forums for .mdf file and found only one post that did not help.
-T
Hello,
it depends on the kind of database you have. Is this a per-user or per-machine database?
You can store your DATA in the CSIDL_COMMON_APPDATA directory (which is usually C:\ProgramData) if the data is shared between users on the machine or CSIDL_APPDATA (which is usually C:\Users\USERNAME\AppData\Roaming) if it is specific to a given user.
Please note that you can't install per-user data files from an elevated running application (e.g. your setup.exe). In this per-user scenario, you have to install the database to a global accessible folder and then copy it (at first application startup) to the per-user location. You have to do this because you don't know how many profiles are on this machine now and in the future.
Hope this helps.
BTW, you have to make sure that your application and the deployment strategy is UAC-aware and (at least) Windows 7 compliant.
Friedrich
The following is a very brief description of how to make an application "UAC-aware" and Win7-compliant:
-- Standard Application:
1. Embed an UAC manifest into your main application (.EXE). A manifest basically tells Windows how aware the program is about the recent Windows versions (and disables "Virtualization" and unwanted legacy Installer Detection Technology). You should include a manifest for Windows 7 because it's fully backward compatible with all previous Windows versions.
2. Request "asInvoker" execution level privileges through the manifest for your application.
3. Code-sign all your application files (e.g. .EXE, .DLL). Use a certificate signed by a CA, e.g. Comodo, VeriSign, etc.
4. Your application should not depend on any administrative APIs. Administrative APIs are APIs that never work without elevation. For example, the RegSaveKeyEx API. Or ACL manipulation APIs, etc..
5. Do not write per-user information or user-writable information to the Program Files folder tree.
6. Do not write to any other protected Windows area (e.g. the OS drive root folder, the "Windows" folder tree, etc.).
7. Do not write to the HKEY_LOCAL_MACHINE or any other protected registry key.
-- Standard Installation:
1. Use an UAC-aware installation system. By default, installations run elevated.
2. Install applications per-machine (all users) and store per-user data in different locations.
3. Do not install Quick Launch shortcuts.
4. Never write to per-user locations from the elevated running installer. That means, never write to the HKEY_CURRENT_USER registry key or to per-user file locations.
5. Launch applications non-elevated at the end of the installation process.
6. Code-sign the installer. Use a certificate signed by a CA, e.g. Comodo, VeriSign, etc.
Note: if you have to install "per-user" data, install it to a common location and as a "first run" action of your main application, copy the data from the common location into a per-user location.
Respect the recommended (default) locations for applications and data files, but provide users with an option to select another installation location for both. A true "Mixed User Application" should work elevated and non-elevated.
That's it :-)
--
Friedrich Linder
Lindersoft
www.lindersoft.com
+1.954.252.3910
SetupBuilder is Windows 7 installation -- "point. click. ship"
-- Official Comodo Code Signing and SSL Certificate Partner