Where is the Application database to be installed?
Hey all,
According to the Windows Vista Software Logo Spec 1.0.doc (Version1.0.0006), Item 2.3 "Install to Correct Folders":
Applications should be installed to Program Files or the user’s AppData folder by default.For per-machine installations, user data must be written at first run and not during the install.Since the install potentially elevates to a different user account during the per-machine install, there is no correct user location to store data at install time.
Our multi-user application is intended to be installed "per-machine", so any user of the machine (or network) could share the application data.
That said, can anybody explain in plain English, where should the application database be installed on the target machineat the time of installation to comply with "Certified for Windows Vista" requirements?
Details: The installation package is a MSI database prepared using InstallShield 12 Pro; .NET Framework 2.0 and SQL Server 2005 Express SP1 are installed as prerequisites. So the only question is about the correct location of Application.mdf and Application.ldf files. (Bear in mind, they might grow up to several GB...)
Thank you in advance for all you help!
[2488 byte] By [
AP_ES] at [2008-2-2]
Hello,
I have the same problem were I have to install configuration files for my applications "per-machine". On WinXp they would be installed in C:\Documents and settings\All Users\Application Data. In Vista, it has been changed to C:\ProgramData.
These configuration files are installed and then can be modified, by the user, through dialogs in our application. The problem that I'm encountering is that the files, once installed, cannot be modified by our application.
If it is not possible to have "per-machine" installations then why not mention it in the "Developer Best Practices and Guidelines for Applications in a Least Privileged Environment" !
One question I have is will Vista permit "per-machine" installations and if so where do we install these files ?
Regards,
Robert
Hi,
The guideline is that:
- \users\Public is the location for Shared User Data
- \ProgramData is location for Shared Application Data
The difference between the two is that the user never directly interacts with the application data, where it would with the user data.
...ok, but if you put your application data in some totally shared folder with other applicaitons, then you are totally unsecure. Other applications could then hose your data, or you could hose their data. I suppose you could create some folder with an obscure name, then put your data in there, but that seems kind of sloppy, and is still not very well protected.
How about this for a solution:
Allow applications 100% free reign over all files and folders within their own folders in the "Program Files" folder.
So, for example, if you have C:\ProgramFiles\MyApplication\MyApplication.exe, then MyApplication.exe, would be allowed to modify, delete, or even corrupt any data it wants, as long as it occurs with the domain of the "C:\ProgramFiles\MyApplicaiton\ folder, or one of it's sub folders. Access outside of C:\ProgramFiles\MyApplication\ would be subject to restrictions.
By doing that, you don't break old applications, you make it easy for developers, and you don't have data strewn all over the place.
Carl.
 Maarten van de Bospoort MSFT wrote: |
The guideline is that: - \ProgramData is location for Shared Application Data |
|
Based on what Maarten states above, I decided to perform some tests (using RC2). I have two different users: one being an administrator and the other being a standard user. I then created \ProgramData\AndreTest. With a program we designed that reads and writes .ini files for testing purposes, I proceeded to write in some .ini files into the directory with no problems. I also verified that I was able to read out of those files.
I then logged out of my admin login and logged back in as the standard user. I used our program to read the .ini files that were there in which the read operation worked just fine. I also created new .ini files in the directory as the standard user...again, that works fine. However, when I tried to write over one of the .ini files that I created from when I was logged into my Admin. account, it created a copy of the file in \Users\[standard-user-account]\AppData\Local\VirtualStore\ProgramData\AndreTest instead leaving the orignal file alone and untouched. I logged off the standard user and went back into my admin. account to see if I could modify the actual files that were created when I was a standard user. What happened was that when I attempted to overite those files, it created the file in \Users\Andre\AppData\Local\VirtualStore\ProgramData\AndreTest and left the original untouched. Yet, those files that I created before as an admin. could still be edited/overwritten right where they reside.
Based on what I wrote above, here is what would most likely happen with our machine tool if there were two different users:
User_1 (assume .ini file was created by User_1 to begin with) logs in and runs the software that controls the machine tool. The .ini file reports that the machine tool's cutting head is at the X,Y coordinates of (4, 8). After a few hours, User_1 closes the software, which saves the final coordinates at (2, 1) before it closes. User_1 then logs out of Vista.
User_2 comes and logs into the computer and runs the software. His initial cutting head position is at (2, 1) because that is where User_1 stopped. User_2 is done with his job and the cutting head is at (5, 10). User_2 closes the software which saves the cutting head position as it closes, but because User_2 wasn't the original author of the .ini file, Vista creates the directory structure under User_2's VirtualStore directory and saves a copy of the original .ini file there. User_2 logs out of Vista.
User_1 comes back and logs in. She runs the controller software which accesses the original .ini file and reports that the cutting head position is at (2, 1) when the head is actually at (5, 10).
My question is how to we make sure that every user is reading from and writing to the same file (and not a VirtualStore file under their respective User account) so they get the correct data?
First, make sure the files are ACL'd appropriately. Then, manifest your exes and declare a requestedExecutionLevel. The presence of the requestedExecutionLevel in the manifest will disable file virtualization for that exe. See the 'manifest files for vista' thread, which has a few important caveats: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=463884&SiteID=1
Hello,
Is there any specific environment variable that tells me which is the public folder? Or is it safe to assume that %systemdrive%\users\public will always be the public folder.
Thanks,
Bobby.
%Public% will get you there. This doesn't work for xp or below and Not sure how to do this in managed code because there is no documentation on %Public% yet. At least that I can find.
thanks mate :-)
happy new year
bobs.
From managed code, use
Environment
.ExpandEnvironmentVariables("%PUBLIC%").ToString()This will return a path such as "C:\Users\Public"
So, using the .Net enumeration System.Environment.SpecialFolder, what is the value for \users\Public and what is the value for \ProgramData?
It is not a good idea to code those paths directly since they can be changed - as we all learned when Vista came out.
Dale
The thread you referred me to makes the solution about as clear as mud.
I do not want to program to "C:\Users\Public" or to "C:\ProgramData". Microsoft has just demonstrated the folly of such constructs by changing, in Vista, all of the documents and settings environment folders that we have been used to for 7 years.
I would like to identify what environment variable or which value from System.Environment.SpecialFolder enumeration will lead me to C:\ProgramData? In these threads, I see that %PUBLIC% will expand to C:\Users\Public.
Is there a place in the Vista SDK documentation or on MSDN that identifies all of the environment special folders and what their intended use is along with the default paths and also what the equivelent pre-Vista (as in Documents and Settings) environment variables/paths are - preferably in some fashion so that an application could be coded with the same environment variable and pass certification for Windows Server 2003, Windows XP, and Windows Vista?
Thanks,
Dale
Dear Maarten,
Although with big delay, but let me thank you for your answer. We used your recommendation to build an installation program for our Certified for Windows Vista application. All the best!
