Where to install configuration files in Windows7

[Chris]

We've just upgraded to LabVIEW 2009 and have started receiving requests to install our applications onto VISTA and Windows7. As far as I can tell the only thing different from previous installers for Windows XP and before is where we can store our Configuration files. Uptil now we have installed them in the C:\Program Files\<application> directory, but I believe we can't or shouldn't do this anymore. My questions are:

1) Using the Get System Directory VI there is about a dozen directories listed (User Home, User Desktop.....Public Application Data etc..) I presume for Single (User) Or Multiple (Public) Users we use the Application Data directories to store our Configuration data?

2) For the Public folders why does the NI Help file say that it is readable but sometimes writable. Is it because two users could be logged in at the same time and one of them is running the application preventing the other user from writing to the Config file?

3) Assuming we can't write to files stored in the C:\Program Files\<application> directory, what happens if we want to modify the <application>.ini file that is associated with the <application>.exe file? And of course if we don't include an <application>.ini file in the installation process when the executable is run for the first time, if there is no *.ini file present, it creates it's own one, but will the OS allow this to happen?

4) We installed an application onto a VISTA machine using the "Public Application Data" system directory type, but trying to find the actual config file proved a nightmare. On my XP machine in Windows Explorer I can easily navigate to C:\Documents and Settings\All Users\Applicaiton Data\<myapp>, but in VISTA it appears to be totally hidden and access is denied even with adminstrator rights. Is this Windows7 normal security settings - sort of defeats the purpose of having human readable/editable config files if the user can actually see them to modify them.

Thanks for any help you can provide - Chris.

[jgcode]

We've just upgraded to LabVIEW 2009 and have started receiving requests to install our applications onto VISTA and Windows7. As far as I can tell the only thing different from previous installers for Windows XP and before is where we can store our Configuration files. Uptil now we have installed them in the C:\Program Files\<application> directory, but I believe we can't or shouldn't do this anymore. My questions are:

1) Using the Get System Directory VI there is about a dozen directories listed (User Home, User Desktop.....Public Application Data etc..) I presume for Single (User) Or Multiple (Public) Users we use the Application Data directories to store our Configuration data?

2) For the Public folders why does the NI Help file say that it is readable but sometimes writable. Is it because two users could be logged in at the same time and one of them is running the application preventing the other user from writing to the Config file?

3) Assuming we can't write to files stored in the C:\Program Files\<application> directory, what happens if we want to modify the <application>.ini file that is associated with the <application>.exe file? And of course if we don't include an <application>.ini file in the installation process when the executable is run for the first time, if there is no *.ini file present, it creates it's own one, but will the OS allow this to happen?

4) We installed an application onto a VISTA machine using the "Public Application Data" system directory type, but trying to find the actual config file proved a nightmare. On my XP machine in Windows Explorer I can easily navigate to C:\Documents and Settings\All Users\Applicaiton Data\<myapp>, but in VISTA it appears to be totally hidden and access is denied even with adminstrator rights. Is this Windows7 normal security settings - sort of defeats the purpose of having human readable/editable config files if the user can actually see them to modify them.

Thanks for any help you can provide - Chris.

This is a great topic, and I look forward to hearing from others.

Currently I store my config (e.g. settings file) into Public Application Data

Public App Data is resolved as C:\ProgramData on 7/VISTA.

So it usually looks like this C:\ProgramData\<Company>\<Project Name>.

And yes, C:\ProgramData is a hidden folder

Currently, I do not install a default settings file with my applications, instead I have the app create the default settings file (if the file does not exist on startup). Thus far I have had no problems with file io access in that location.

However, when only XP was around I used to use a different approach which was to install the config file. (I learned quick that this is a pain anyway because the clients files get removed on an upgrade and they have to be manually/scripted backed up and replaced after install to have settings persist!)

I have noticed with older application where by I install the files to the Public App Data location I can get file io problems. Normally IT has to grant access to allow write in this location and that has fixed the issue. I haven't noticed this in all cases, but I have seen it. So I need to investigate it further. And guess I will experience this more as I work on older projects that have new requirements for the latest OS').

So this is where I store data that I don't want the client to see (private) I usually have a public folder somewhere too that the user defines or I use e.g. C:\<Project> or similar, where a flat file database may sit etc...

I haven't needed to create an app to support different users, I just share the data, but if I did I would make use of the User location.

Cheers

-JG

[Chris]

Thanks for that.

So as you said if you upgrade or un-install your application the data into C:\Program Data\<company>\<Project Name> is unaffected, so I guess this directory will just keep getting bigger.

Which leads me to another question, what if by some slim chance, the application you install has the same name as another application already installed on the computer - I guess it wouldn't really matter unless your Configuration file had the same name too, and that will be extremely unlikely.

[jgcode]

Thanks for that.

So as you said if you upgrade or un-install your application the data into C:\Program Data\<company>\<Project Name> is unaffected, so I guess this directory will just keep getting bigger.

Great point! A utility that asks, "You have uninstalled Application X, do you want to delete Application X's data or keep it on the system?" would be nice. But unless you write your own installer (like VIPM) using the NI one, won't do it.

Which leads me to another question, what if by some slim chance, the application you install has the same name as another application already installed on the computer - I guess it wouldn't really matter unless your Configuration file had the same name too, and that will be extremely unlikely.

The chances would be slim, but that is why I usually use a folder that is <company>\<project> with the company being ours - unless its a commercial product and not custom, then its usually the clients company name. That way we can control this internally.

[Daklu]

Great point! A utility that asks, "You have uninstalled Application X, do you want to delete Application X's data or keep it on the system?" would be nice. But unless you write your own installer (like VIPM) using the NI one, won't do it.

I've been looking into using a professional installer (InstallAware Studio) for creating installers. It is turning out to be much more complicated that I originally expected, but I believe it will make things like supporting different Windows versions, applying patches, upgrading to new versions, etc. a lot easier to manage.

[jgcode]

I've been looking into using a professional installer (InstallAware Studio) for creating installers. It is turning out to be much more complicated that I originally expected, but I believe it will make things like supporting different Windows versions, applying patches, upgrading to new versions, etc. a lot easier to manage.

Please let us know how you go!!!

Although the NI installer is great, there have been times where a custom one would be ideal.

I have had this idea previously, but never attempted to implement it:

I have thought about doing things with a CD installer --> Using a batch file or similar, install the LabVIEW Run Time first if not already installed, then launch an exe off the CD that is a GUI dashboard that would have options for installing drivers, dotNET, support software etc... (this would look nicer than a CD popup autorun menu using autorun.inf etc...)

I don't know how this would go?

But I thought it would be nice for when you have a large application that contains e.g. DAQ and Analysis.

Some users would install e.g DAQmx drivers if they want to collect data

Other users might just want to Analyse data so they don't need the Drivers and can avoid a large install.

If they ever wanted to collect DAQ then to install the drivers they just have to load the CD, and the dashboard would launch and they could select it.

(In the app you would just precheck what is installed, and if e.g. no DAQmx then those VI could not be launched (dynamically))

Has anyone else done something like this?

[Mads]

The problem with the public application data folder is that only the user that first ran the program will have access to the configuration files the application created under ProgramData. One might say that the data is not really public...ironically enough. So if a second user logs in and you want that user to be able to see the same application configuration and maybe also do things that will affect it - ProgramData will not work unless you change the access properties of the files in programData. There are plenty of web sites that discuss this dilemma, and it's the reason why I suggested this idea on the idea exchange.

This is why we normally use the user's application data folder instead if it's a user-run program, but we use the ProgramData folder if it's a service that always runs under the same user.

Mads

This is a great topic, and I look forward to hearing from others.

Currently I store my config (e.g. settings file) into Public Application Data

Public App Data is resolved as C:\ProgramData on 7/VISTA.

So it usually looks like this C:\ProgramData\<Company>\<Project Name>.

And yes, C:\ProgramData is a hidden folder

Currently, I do not install a default settings file with my applications, instead I have the app create the default settings file (if the file does not exist on startup). Thus far I have had no problems with file io access in that location.

However, when only XP was around I used to use a different approach which was to install the config file. (I learned quick that this is a pain anyway because the clients files get removed on an upgrade and they have to be manually/scripted backed up and replaced after install to have settings persist!)

I have noticed with older application where by I install the files to the Public App Data location I can get file io problems. Normally IT has to grant access to allow write in this location and that has fixed the issue. I haven't noticed this in all cases, but I have seen it. So I need to investigate it further. And guess I will experience this more as I work on older projects that have new requirements for the latest OS').

So this is where I store data that I don't want the client to see (private) I usually have a public folder somewhere too that the user defines or I use e.g. C:\<Project> or similar, where a flat file database may sit etc...

I haven't needed to create an app to support different users, I just share the data, but if I did I would make use of the User location.

Cheers

-JG

[Mads]

Here's a good site to look at:

http://blogs.msdn.com/cjacks/archive/2008/02/05/where-should-i-write-program-data-instead-of-program-files.aspx

The discussion on the page highlights some of the problems people have with how things work in Vista/Win7.

We've just upgraded to LabVIEW 2009 and have started receiving requests to install our applications onto VISTA and Windows7. As far as I can tell the only thing different from previous installers for Windows XP and before is where we can store our Configuration files. Uptil now we have installed them in the C:\Program Files\<application> directory, but I believe we can't or shouldn't do this anymore. My questions are:

1) Using the Get System Directory VI there is about a dozen directories listed (User Home, User Desktop.....Public Application Data etc..) I presume for Single (User) Or Multiple (Public) Users we use the Application Data directories to store our Configuration data?

2) For the Public folders why does the NI Help file say that it is readable but sometimes writable. Is it because two users could be logged in at the same time and one of them is running the application preventing the other user from writing to the Config file?

3) Assuming we can't write to files stored in the C:\Program Files\<application> directory, what happens if we want to modify the <application>.ini file that is associated with the <application>.exe file? And of course if we don't include an <application>.ini file in the installation process when the executable is run for the first time, if there is no *.ini file present, it creates it's own one, but will the OS allow this to happen?

4) We installed an application onto a VISTA machine using the "Public Application Data" system directory type, but trying to find the actual config file proved a nightmare. On my XP machine in Windows Explorer I can easily navigate to C:\Documents and Settings\All Users\Applicaiton Data\<myapp>, but in VISTA it appears to be totally hidden and access is denied even with adminstrator rights. Is this Windows7 normal security settings - sort of defeats the purpose of having human readable/editable config files if the user can actually see them to modify them.

Thanks for any help you can provide - Chris.

[Daklu]

Good links Mads. I wasn't aware of the restrictions on the ProgramData folder. After reading through the blog and comments I understand the reasoning behind making it work the way it does. It appears the issue can be resolved by setting proper permissions on the application's folder in ProgramData; however, there is no easy way to do that from within the Labview installer. Kudo for your idea on the exchange.

[jgcode]

[Cross Posted in ni.com]

[Chris]

In the days of LabVIEW 5, 6 and 7 when the LabVIEW Application Builder was pretty basic I used InstallShield Express to build professional installations. However this package costs extra money and you have to learn and manage a whole new package in parallel with LabVIEW's Application Builder.

I basically used the LabVIEW Application Builder to create the EXE and InstallShield Express to create things like Splash Screen, Licence Info, Shortcuts, Extra plugins etc.

However it now seems that most of these features are included in the LabVIEW 2009 Application Builder and I can only assume/hope that this is going to improve and have more features in the next release.

So personally I don't think it's worth going down the path of using Third Party Installers.

Chris

[jgcode]

In the days of LabVIEW 5, 6 and 7 when the LabVIEW Application Builder was pretty basic I used InstallShield Express to build professional installations. However this package costs extra money and you have to learn and manage a whole new package in parallel with LabVIEW's Application Builder.

I basically used the LabVIEW Application Builder to create the EXE and InstallShield Express to create things like Splash Screen, Licence Info, Shortcuts, Extra plugins etc.

However it now seems that most of these features are included in the LabVIEW 2009 Application Builder and I can only assume/hope that this is going to improve and have more features in the next release.

So personally I don't think it's worth going down the path of using Third Party Installers.

Chris

VIPM has a LabVIEW-built installer that looks really sweet.

This approach would be quite powerful and flexible (no need to learn another language/protocol and no need for additional costs)

Of course there would be the overhead in developing such a thing

It would have to be reusable/configurable and used across multiple projects for it to be worthwhile (to me) ...if only I had the time...

For now NI's one is great.

Maybe that is an option?

[Rolf Kalbermatter]

VIPM has a LabVIEW-built installer that looks really sweet.

This approach would be quite powerful and flexible (no need to learn another language/protocol and no need for additional costs)

Of course there would be the overhead in developing such a thing

It would have to be reusable/configurable and used across multiple projects for it to be worthwhile (to me) ...if only I had the time...

For now NI's one is great.

Maybe that is an option?

I have also gone the path of (very simple) LabVIEW installers. It works quite nice and when I did it in LabVIEW 7.1 I even could make it self contained by only copying a handful of LabVIEW runtime files into the same folder as the executable itself, so that it would work even with no LabVIEW runtime installed. Doing the same in newer LabVIEW versions gets however increasingly difficult and having to run an installer first for the LabVIEW runtime to be able to run an installer then for your application is not a good option .

Another application I have worked with is InnoSetup.

Advantages: Free, powerful, fully scriptable.

Disadvantage: if you need to do anything non standard you have to write a script in a Pascal like language.

[jgcode]

I have also gone the path of (very simple) LabVIEW installers. It works quite nice and when I did it in LabVIEW 7.1 I even could make it self contained by only copying a handful of LabVIEW runtime files into the same folder as the executable itself, so that it would work even with no LabVIEW runtime installed. Doing the same in newer LabVIEW versions gets however increasingly difficult and having to run an installer first for the LabVIEW runtime to be able to run an installer then for your application is not a good option .

Hi Rolfk - the LV7.1 installer sounds cool.

Any application is going to need a LabVIEW run-time, so having it installed before you run the install would be all that would be needed.

I don't think that is much of an issue. You can't really get around it with LabVIEW (although it seemed you did with an older version! )

[jgcode]

Any movement on this topic?

I saw some chatter on Info-LabVIEW but didn't follow it.

Just wanted to check if anyone has any new thoughts/ideas on what they do so that Settings files that can be shared for multiple logins??

(Mads post sums it up - so currently I have to ensure Admin rights to that folder (e.g. CommonAppsDataFolder).

What about the location - Users\Public\Public Documents?

Although the blog post says that you need to set ACLs at install time, from the permissions it seems that Everyone can access it anyway?

[Daklu]

What about the location - Users\Public\Public Documents?

Although the blog post says that you need to set ACLs at install time, from the permissions it seems that Everyone can access it anyway?

Yeah, I believe that location would work for machine-wide data/config files. The downside is that in XP that ends up in the "My Documents" part of the Start menu, which some users don't like.

[jgcode]

Yeah, I believe that location would work for machine-wide data/config files. The downside is that in XP that ends up in the "My Documents" part of the Start menu, which some users don't like.

Cheers for the feedback - I will have to check this out.

[JG blows dust off of old XP laptop hidden under a pile of even more crap].

[Daklu]

So I whipped up a little table that correlates the locations from 'Get System Directory.vi' and the Windows Installer variables (used with the built-in install builder) with Windows XP and Windows 7.

None of the locations that you can easily get to via Get System Directory and Windows Installer are appropriate for a machine-wide config file. If you create the config file at run time instead of installing it, the Public Documents tag for Get System Directory will work. You can avoid having them show up in each users' My Documents folder by stripping "Documents" and appending "AppData\MyApp\MyApp.ini." It's not ideal, but it's workable.

Windows 7 has a %PUBLIC% environment variable that maps directly to Users\Public, but that variable doesn't exist in XP so it's not much help with cross-os compatibility.

[jgcode]

So I whipped up a little table that correlates the locations from 'Get System Directory.vi' and the Windows Installer variables (used with the built-in install builder) with Windows XP and Windows 7.

None of the locations that you can easily get to via Get System Directory and Windows Installer are appropriate for a machine-wide config file. If you create the config file at run time instead of installing it, the Public Documents tag for Get System Directory will work. You can avoid having them show up in each users' My Documents folder by stripping "Documents" and appending "AppData\MyApp\MyApp.ini." It's not ideal, but it's workable.

Windows 7 has a %PUBLIC% environment variable that maps directly to Users\Public, but that variable doesn't exist in XP so it's not much help with cross-os compatibility.

Kudos for your time doing this!

[crelf]

To add another layer of complexity, we usually use the registry for product application settings

[ShaunR]

To add another layer of complexity, we usually use the registry for product application settings

Making excellent use of LabVIEWs x-platform capabilities then