.NET provides a mechanism to input runtime information into an application via an XML configuration file. These are used for a variety of reasons, such as picking a logging level or providing networking information (hostname, port, IP, protocol, etc). LV itself doesn't need or use these configuration files itself but your application may want them.
For example, if you want to use .NET remoting to communicate to another object in a different AppDomain, process or machine, you typically aren't going to want to hardcode all of that information in your VI. Put it into the configuration file.
Under .NET, the configuration file is named after the executable (for example, notepad.exe.config) and is in the same directory as the program. For LabVIEW, obviously, that doesn't work as well so we have some different settings for where to find the configuration file.
LabVIEW 7.x
As described in the LV User's manual, you can create a configuration file for any VI by naming it after the VI, such as add.vi.config.
However, the configuration file for a VI is only loaded if the VI is run as a top level VI. If it's called as a subVI, the configuration file for the subVI is ignored. This is due to the fact that configuration files must be specified when the AppDomain is created, and as I've discussed in previous posts, that's when the top level VI runs.
In general this shouldn't matter for most applications, but it's something to remember...especially when running subVIs independently for debugging or other reasons.
Note that if you are using a built EXE, then the configuration file follows the .NET rules (add.exe.config).
Constellation
If you read my post on Constellation then you know that we have changed the rules of when AppDomains are created for VIs. This is a big step forward, I believe, as it allows for the sharing of .NET references across VIs much more easily. But it does mean that some things must change.
First and foremost is the requirement that you use a project to access the configuration file. This was a difficult requirement to finally decide on but if you think about it, it does make sense. In Constellation, rather than being tied to a VI, the AppDomain is either global (non-project world) or per-project. Since there's no "home" for the global case, it's kinda hard to create a configuration file in it.
Thus the naming rules for Constellation are as follows...
- For Projects, it is named after the project (MyApp.lvproj.config)
- For Built EXEs, things haven't changed - MyApp.exe.config
- For Built DLLs, you can now create configuration files for each DLL - MyApp.dll.config. As you'd expect, you put this into the same directory as the DLL.
Comments