Best folder location(s) for application ini

[John_P1]

In searching for some documentation to address this, I came across a post on Stack Overflow.  The author provides a link to the relevant Microsoft documentation which states the following:

Windows provides specific locations in the file system to store programs and software components, shared application data, and application data specific to a user:

• Applications should be installed to the Program Files folder by default. User data or application data must never be stored in this location because of the security permissions configured for this folder (emphasis added)
  
  
• All application data that must be shared among users on the computer should be stored within ProgramData
  
  
• All application data exclusive to a specific user and not to be shared with other users of the computer must be stored in Users\<username>\AppData
  
  
• Never write directly to the "Windows" directory and or subdirectories. Use the correct methods for installing files, such as fonts or drivers
   
• In “per-machine” installations, user data must be written at first run and not during the installation. This is because there is no correct user location to store data at time of installation. Attempts by an application to modify default association behaviors at a machine level after installation will be unsuccessful. Instead, defaults must be claimed on a per-user level, which prevents multiple users from overwriting each other's defaults.

I know LabVIEW doesn't follow this with LabVIEW.ini--I'm not sure of the reasoning behind this.  In order for this to work, I'd imagine the LabVIEW installer creates LabVIEW.ini as read/write (you can add "unlocked" files to the Program Files direcotry using a LabVIEW-built installer if you want to mimic this behavior yourself), but this isn't what is recommended by Microsoft.  I know other NI products have run into permissions issues in the past, so personally I'm going to continue following the Microsoft guidelines.

Best Regards,

[John_P1]

---

GriffinRU wrote:

HKLM\SOFTWARE\YOUR APP -> create during install with admin credentials and use it for configuration parameters

Do not use registry (unless you are admin and know what you are doing) for data sharing. Use Labview variables...

-Artur

---

I am under the assumption that we are talking about application configuration data that might be prone to change after the installation (e.g. menu preferences or some sort of thing).

Best Regards,

[GriffinRU]

John,

We can discuss this forever, your view point and Microsoft documentation are good points but as long as you have .ini file (if you plan to use it for configuration purposes) associated with given application - why creating another one. If one day LabVIEW would follow Microsoft recommendation (not the rule) you will still be glad to stick with LabVIEW's ini-file location -> perfect legacy plan.

Registry editing without admin rights is possible but a little bit complex to set up. If your program runs without admin rights - follow Microsoft and store data in ProgramData folder or use variables, mentioned before...

Bottom line for application's configuration data (size, location, preferences and other GUI junk) I recommend to use LabVIEW's ini file and stay with it and let LabVIEW developers worry about it's location. For user or application data sharing use whatever is better suited for you, Microsoft recommendations, run-time engine, shared variables, TCP, UDP, memory, registry anything what you are comfortable programmatically with and can easily share with others.

-Artur

[kbbersch]

The app.ini file in the application's Program Files folder contains setting that shouldn't change after installation.  It contains the settings the run-time engine needs.  I always use the Program Data folder for settings that are not user specific and the User folder for setting that are user-specific.  That can mean having two configuration files but a job worth doing is worth doing well.

[GriffinRU]

Sure, multiply your foot-print!!!

-Artur

P.S.

JUST to make sure we are on the same page...

Labview ini file:

• stores recent colors
• server settings
• anything related to application property nodes you change programmatically

Registry (or yes only admin) really?! How about IE stores recent webpages, locations/sizes of given popups (windows) and fonts and colors...

If you ask were to store your data then you should follow recommendations from above but if you seasoned programmer than you should be efficient in using bits.

And last one:

While it is nice to follow Microsoft recommendation and styles, LabVIEW "not good" in natively know what happen to the system while it wasn't running. Example: someone with admin rights could change ProgramData folder location on the system...and what you are going to do...

[kbbersch]

Actually, the application has rights to the Program Files folder that the user doesn't have so it can write changes to the app.ini file but the user can't.

If someone were to move the Program Data folder the system would know it and, if you use system environment variables instead of hard-coding the path, you won't have any problem with your configuration file going missing.  You shouldn't even notice the change.

[GriffinRU]

🙂 so now your program has other rights then you do (who program it) 🙂

Never mind, I express my point of view, backed up by years of working in Windows enviroment and found it is very difficult to please everyone, but as long as your code is simple and file location is trivial and follows LabVIEW way, you should be 99% closer to get happy customers.

I am assuming that LabVIEW has a built-in function to get Windows enviroment variables and adjusts to them on-the-fly without you programming how to handle that. Try to change dpi with fonts on your computer and check how your LabVIEW interface will adapt to that...

-Artur

[kbbersch]

The System, which actually launches the program, has system rights that are different than the user rights.  The run-time environment can use those rights to write to the app.ini file even when the user cannot.  It's a problem I ran into when I did use the Program Files\app\app.ini file to store configuration data, which is why I no longer do that.  I've done IT support in the past and have been programming with LabVIEW for 13 years and text-based languages before that.  You can do things a lot of ways but my experience tells me the use of the ProgramData folder and User folder is the best way to store configuration data.  Your mileage may vary.

[GriffinRU]

Again, just pure programming issue my friend. If you had a chance to create this file you have rights to use it forever as long as you know how to play in windows by rules. And, yes LabVIEW doesn't have built-in functions to do that (hopefully yet), but doesn't mean that you as programmer cannot solve it.

Not to go too far into how to make it editable (I can think of couple at least), think of background service with system rights (created when you were admin) to do your dirty laundry...

-Artur

[kbbersch]

---

@GriffinRU wrote:

Again, just pure programming issue my friend. If you had a chance to create this file you have rights to use it forever as long as you know how to play in windows by rules. And, yes LabVIEW doesn't have built-in functions to do that (hopefully yet), but doesn't mean that you as programmer cannot solve it.

Not to go too far into how to make it editable (I can think of couple at least), think of background service with system rights (created when you were admin) to do your dirty laundry...

-Artur

---

You're going through a lot of work to do the hard way what the operating system already gives you an easy way to do.  You do whatever you want but I have too much to do to waste time reinventing an inferior wheel.