Virtual Store Redirection

[chelseatech]

I'm a software developer with users running a range of windows. One of my apps is a dot Net windows service and a user management form. The two share files in the program folder, but as they could be running under different accounts, those files are relocated into different user folders by that virtual store redirection feature in Vista.

One solution was for my application to install itself in an c:\App folder, but that's not the way other version of windows want applications to install.

The best solution was to have a config file in to redirect all the data files to a c:\Data folder. The MS apps like NotePad and File Manager don't have any problem with these folders, but the MS guys are saying they don't trust us developers to maintain the ini and config files from within our own applications.

Anyone got any thoughts or solutions on this?

Editor and Publisher of Crystal Clear

http://www.chelseatech.co.nz/pubs.htm

 

[linney]

See if any of the information in here is of any help?

Vista - same file name, different file contents
thread1583-1435573

Make older programs run in this version of Windows

http://windowshelp.microsoft.com/Windows/en-US/help/bf416877-c83f-4476-a3da-8ec98dcf5f101033.mspx

 

[chelseatech]

I can understand why you aren't allowed to load things against "LOCALMACHINE" in the registry, but when one app and user changes a config file in the program folder, I can't see why other users can't use that new value.

We've had ini files for years that do this. It's a real pain, and I can't see why a service pack doesn't fix this. Even sub folders are messed up. I don't know how it goes for MS own applications like SQL Server that have a "Database" folder for all their databases. Are they redirected as well? If the account running the service is changed, all the subfolders will be in a different place.

Editor and Publisher of Crystal Clear

http://www.chelseatech.co.nz/pubs.htm

 

[dilettante]

The root of the boot drive is also a protected area, and specifically not a place to dump things like application folders.

The real change in Vista is that it enforces Windows design guidelines that have been around since late in the Windows 95 cycle, when the new shell was introduced as an update with the release of IE 4.0. Virtualization is a legacy application compatability crutch.

While most of the materials Microsoft produced to assist developers arrived on the scene during the late Vista betas, you can still find some of it. It is late in the game, so some documents and tools are harder to find, but most are easy to locate and new documents are still produced from time to time.

Windows Vista Developer Story is a place to begin.

First you might want to read Windows Vista Application Development Requirements for User Account Control Compatibility as a general introduction to UAC related issues. Example:

Virtualization Recommendations

Virtualization is intended only to assist in application compatibility with existing programs. Applications designed for Windows Vista should NOT perform writes to sensitive system areas, nor should they rely on virtualization to provide redress for incorrect application behavior. When updating existing code to run on Windows Vista, developers should ensure that, during run-time, applications only store data in per-user locations or in computer locations within %allusersprofile% (CSIDL_COMMON_APPDATA) that have access control list (ACL) settings properly set.

Cry we may, but this isn't going to change anytime soon. Much of this same mechanism is in Windows 2008 Server, and can be expected in Windows 7 too.

Properly written and installed applications seldom raise a UAC prompt. You might also consider that 64-bit and several categories of 32-bit applications don't have virtualization shims applied either: they just error out when they break the rules.

 

[linney]

when one app and user changes a config file in the program folder"

Have you checked the Access Permissions in Program Files and maybe consider changing them appropriately, so that the Virtual Stores do not have to be used? By Default the write permission is not granted.

 

[dilettante]

Oh, I forgot...

In general, things like per-machine INI files are meant to be installed into a directory like:

[tt]{CommonAppDataFolder}\<company name>\<app name>[/tt]

Your installer should set security on your INI file (or your whole [tt]<app name>[/tt] folder) to permit Full Access for Everyone if that is what your application requires. Since this is an administrative issue it is normally done as part of installation.


None of this is really new, and programs and setup packages designed for Vista should work just as well downlevel.

 

[dilettante]

The point of making folders under Program Files protected against writes is to keep malware from altering or replacing any code that a user might innocently run. So altering security on these folders is not the right thing to do.

Put data into a proper data location instead.

 

[Nelviticus]

You could use this:

string myPath = Environment.GetFolderPath(Environment.SpecialFolder.CommonApplicationData);

Regards

Nelviticus

 

[Bubb]

The absurdy with this whole situation is enough to drive you around the bend. So basically you have to use CommonApplicationData to store your applications per machine data. The reasoning being that you dont want to give RW permisions to "Program Files\my app" yet you have to set RW permission on the CommonApplicationData folder? Well you might as well set these permission in the Program files directory and make all your app files read only except for the ones that you want to be RW. The fact is I know most tech admins dont want any programs altering folder permissions no matter where they are.

There whole thing is a farce and i fail to undertstand why you guys defend MS when we should be starting to vote with our wills and begin devoloping products using non-ms devolopment tools and look to using Non MS OS's where possible in our networks. We keep giving MS chance after chance because they cater to infant minds with pretty icons and wizards. Thier products are a nightmare, they may be pretty but you spend so much time researching and reading that could be better learning new products that work. Its not meant to be this hard. Look at all their products ISA,Exchange,AD, Visual studio, Vista. They are just painful. On the other hand look how complex a concept Virtualisation is and you jump on VMware and its intuative and simple. The problem is MS has sucked everyone in and we are now so depedant on them that we dont have the balls to make the hard decisions to back track and get out of this MS mess we are all in.