PDA

View Full Version : Setting Data Paths in VISTA



LeftSeat
04-22-2007, 12:20 PM
From the first commercial app I ever released, I've had the app generate its dynamic data files in the same directory as the EXE. With Virtualization in Vista, that's no longer an option if the app resides in a protected location such as "Program Files." The data files will be generated alright, but in a virtual folder for each individual user. In other words, when the program writes to the protected location, Windows redirects the write operation to a user-specific location. The application thinks it is writing to Program Files, but in reality a file gets written to a second Program Files directory in the user's Virtual Store.

The obvious solution is to simply make your own INSTALLDIR (in my case, C:/PrintFire/MorningFlight). That avoids virtualization, and Installshield Express readily uninstalls apps residing outside the Program Files folder as well. Often though, the obvious solution isn't the best solution. Sometimes it's in fact the last thing you'll want to do.

Anyone know of any drawbacks or pitfalls with installing an app outside the Program Files directory? It shouldn't be, since users can change the default directory during the installation and install pretty much any application anywhere they like. Which is, of course, a problem of its own. Nothing prevents a user from adding "Program Files" to the default INSTALLDIR and promptly get virtualized by Vista.

MichaelU
04-23-2007, 10:36 AM
The answer depends on why you need this. What is the problem with several users each having their own set of the dynamic files - are they large (read-only is fine), do they need to be shared (read-write), or is it something subtle? The option of using another arbitrary directory may avoid virtualized file access, but will not alone grant write access to non-administrative users. It also runs against Vista Logo requirements, if those matter to you.

LeftSeat
04-23-2007, 11:38 AM
Thank you, Michael, for your quick reply. My apps (management software for printing companies) aren't user-specific, which is why I can't have the dynamic data files reside in each user's virtual store. They're company-wide files for estimates and invoices and such. Access should be pretty much along the lines of QuickBooks - with a single set of files accessible by all users for both reading and writing. At this point, they don't need to be shared across a network, and I'm not concerned about Vista Logo requirements.

In trial runs, with myself as administrator and a dummy standard user account, I've had no problems writing to files in a C:/PrintFire/MorningFlight folder created by Installshield Express that contained both the .exe and the data files. Both I and the standard user have ready access. I should add that all the dynamic files are created by the app if they don't already exist. Those files are not part of the installation.

MichaelU
04-23-2007, 03:35 PM
This sounds like it would be best handled by installing under ProgramFilesFolder for INSTALLDIR, but then updating the application to use a subfolder of CommonAppDataFolder (http://msdn2.microsoft.com/en-us/library/aa367992.aspx) for its shared files. If that is not an option at this point, your non-ProgramFilesFolder workaround may be the best option, but I cannot recommend it.

LeftSeat
04-23-2007, 07:02 PM
I'll experiment some more and then post the results. My main concern at the moment is that some of my more than 3,000 users will upgrade to Vista and see their existing data files disappear into Vista's virtual world. The program, currently installed on their machines in C:/Program Files/PrintFire/MorningFlight, will load under Vista. When it fails to find its data files in the INSTALLDIR, it will create new files, with predictable results.

Unless I'm missing something, the folks at Redmond could maybe have thought a little deeper! Then, too, there is the user's option to install either within or outside the Program Files folder. Because of new rules and selective virtualization (programs installed by the user within the Program Files folder get virtualized, those installed outside do not), that may yet turn out to be an invitation to a quick game of Database Roulette.

Appreciate the help, Michael. I fully understand that you can't sanction non-approved workarounds. Should I decide to skirt the rules, I may at some point find myself out on a limb.

MichaelU
04-24-2007, 10:12 AM
I don't think files will disappear. In the common case of a single user per machine, there will either be an error writing them in the first place, or they should remain accessible via the name they were saved as. The only issue comes up when another user wants to access the same files, but cannot access the first's virtualized location. (Note: I haven't read up on the FS virtualization here, so I could be 100% wrong)

In your scenario I don't know how common the cross-user sharing is. I would expect it might be a degraded case if each user has their own copy of these files, but it doesn't sound explicitly harmful. If that's true, try to schedule a CommonAppDataFolder rewrite of the software for a future release, and see if the virtualization will result in an acceptable behavior pattern. If it's not acceptable, see if you can move up the rewrite.

LeftSeat
04-24-2007, 05:27 PM
True, files don't actually get deleted, they merely disappear from the radar screen. I wouldn't expect the average user to look for them in C:\Users\(User's Name)\AppData\Local\VirtualStore\Program Files\INSTALLDIR, where Vista puts them. In Microsoft's defense, those missing files will populate the list box when the user clicks the "Compatibility Files" button.

You're also correct about other users not being able to access the original user's virtualized location. What's more, any customer added to ACME Supply's customer database maintained by Jane won't make it into ACME Supply's customer database maintained by John. When programs are installed into the Program Files folder, Vista will absolutely maintain two separate data files. Great for each user's personal photo and music libraries, not so great for corporate customers and invoices. In my case, separate folders are explicitly harmful and make your recommendation to locate common data files in the CommonAppDataFolder a no-choice requirement. It's either that, or keep business applications out of the Program Files folder.

For the time being, and until I port my applications to .NET, I'll take the second route and steer clear of Vista's virtualization. Hours of testing have yet to reveal any ill effects, all users have ready access (with permissions set by my applications), installs and uninstalls are flawless, and with all data files in the same folder as the .exe, the program will always find them without a road map.

The workaround isn't perfect. Some administrator can still insert "Program Files" into the path during installation, thereby opening the door to separate, virtualized files for each user. Guess I'll deal with that in .NET. Besides, as long as there's only one user per machine (the common case you mentioned), virtualization is not a factor. I have yet to run into an instance where Vista didn't remember where the files were.

vickyg2003
05-01-2007, 04:02 PM
I'm struggling with this same issue. I need my database to be accessible by anyone who logs onto a particular machine.

Virtulazation under Vista messes with the application.

I had though of CommonAppData, but that requires the user to have admin rights.

I'd like to put it in Common Shared Documents or Public Documents, but Express doesn't seem to have a predefined location for that.
Is there a work around, or an installshield product that supports this?

LeftSeat
05-04-2007, 05:49 AM
I haven't found where Installshield supports CSIDL_Common_Documents (which apparently maps to c:\users\public\documents on VISTA), but that seems to be the preferred location for common access by multiple users on the same machine. See the exchange on

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1213890&SiteID=1

bryanwolf
05-04-2007, 12:10 PM
There hasn't ever been a way to write to CommonDocuments or anything of that nature. There's not really a realistic way of accomplishing that task without rolling your own custom action for it.

As far as the manner in which this is presented: MSI has changed to enforce the rules they've been preaching for some time. C:\ProgramData is a solution to prevent and override applications writing to the C:\Program Files area. If you notice, the Users actually does have rights to write to any subfolder of C:\ProgramData as a result of a specialty inheritance. So basically, this is the solution to all of lifes' problems. C:\Users\Public\Roaming\AppData is definitely not the area you want to go putting information.

From the Virtualization perspective, applications that have a manifest could easily workaround this issue by requesting Administrative privileges as an option. Injecting manfiests isn't trivial, but a suitable solution if you need one without a rewrite.

vickyg2003
05-04-2007, 01:57 PM
When I put things in the ProgramData\MyFolder\myfile with adminstration rights then log in as a user with plain user rights, the user isn't allowed access to update the files. WHAT AM I DOING WRONG!

Dan Tallent
06-08-2007, 10:18 AM
The whole point to this exercise is to force developers to follow the rules that Microsoft has been preaching for years. Adding a manifest to run your application as an administrator defeats this purpose.

I am running into the same problem as vickyg2003. I have separated the program from the data as required for Vista. But now when I attempt to update the files in the [CommonAppDataFolder] I get an error about the files being read-only.

I attempted to use InstallShield to force the permissions for this folder, but the install failed because it could not update the permissions. What is the suggested method for allowing a standard user to modify the files in the
[CommonAppDataFolder] ? Does InstallShield have a method to make this possible on Vista?

datamagnet
05-15-2012, 11:16 AM
From the first commercial app I ever released, I've had the app generate its dynamic data files in the same directory as the EXE. With Virtualization in Vista, that's no longer an option ......

The obvious solution is to simply make your own INSTALLDIR (in my case, C:/PrintFire/MorningFlight). That avoids virtualization, and Installshield Express readily uninstalls apps residing outside the Program Files folder as well. Often though, the obvious solution isn't the best solution. Sometimes it's in fact the last thing you'll want to do.
....
Anyone know of any drawbacks or pitfalls with installing an app outside the Program Files directory? .

I hear you .. I am encountering the same virtual Store Making my life a living &^*&(!. I too have a DB that all users need to get to and write to.

Anyway .....

Am I doing something wrong. in IS, I added a folder xGEL Data Systems under the Destination Cmputer. I figured this would install my program under the target computer C: Drive. Not so. it installed it on my attached USB portable drive "G:" What the???????

Any Ideas? Do I need to somwhow "force" install to the C: Drive? What setting do I use to do that.

datamagnet
05-15-2012, 01:29 PM
Figured it out ...