Does .NET 3.5 Framework support adding configuration files related to an assembly in GAC?
As an example, if assembly XXXXXX.Manufacturing.Equipment.dll needs configuration values it would expect to find them in file XXXXXX.Manufacturing.Equipment.dll.config located in the same folder as the XXXXXX.Manufacturing.Equipment.dll itself.
It is not supported in .NET 1.1 and .NET 2.0. There are many work arounds to do it.
All kinds of information is appreciated.

The configuration file usually has the name of the executing application, not the loaded DLL.

e.g. If your application MyApp.exe loads dll MyDll.dll which is in the GAC then the configuration file it looks for it called MyApp.exe.config - even the code inside MyDll.dll.

/- Sam Judson : Wrox Technical Editor -/

Sam,

I understand that concept. That is how it works in .NET1.1 and .NET 2.0. I was wondering if something like that is supported in .NET 3.5 framework.

We need to make a major policy decision in our organization based on that information.

We have developers who are putting assembly specific configuration files into the GAC and cluttering it. Developers have found work around to do it instead of referring to the application specific configuration file(MyApp.exe.config)

I hope I have made myself clear on the information required.

Hi

I still don't know how you can store a .config file in the GAC - I have never heard of that at all.

Though you can load a specific named configuration file its certainly not the normal thing to do.

You should also be aware that .Net 3.5 is no more than .Net 2.0 with more DLLs - it uses exactly the same GAC, and exactly the same core CLR.

/- Sam Judson : Wrox Technical Editor -/

...
So did you answer your own question?

I would make the observation that the "Global Assembly Cache" is for assemblies and nothing else. If you developers *are* putting config files in the GAC, how are they consuming them?

-Peter
compiledthoughts.com

Here is a post I found on MSDN forums.

http://forums.msdn.microsoft.com/en/...-fd7603f55ae0/

and on some blog

http://kyletillman.net/blog/post/Con...ssemblies.aspx

I guess the developers are using this technique.

Even in the instance above there is always a place that the 'executing application' can place code so that it is accessible via the standard configuration settings.

For example, if I create a .Net DLL which is COM visible, and call it from a VBScript file which I run using cscript.exe, then I can put configuration settings in a file called cscript.exe.config.
Likewise with COM+ they are loaded by dllhost.exe, so again the dllhost.exe.config file can be placed in the system32 directory - or you can specify a configuration directory under the COM+ settings.

So I cannot see a reason to have to place configuration files in the GAC. If you have a particular case that you cannot work out then let us know.

/- Sam Judson : Wrox Technical Editor -/

Sam,

I am responsible for a very critical application which is used worldwide as a standard part of our IT infrastructure. The application manages deployment of in-house applications and files on Microsoft Windows based workstation and server machines.
The user wants to add a feature in the application which will support adding configuration files in the GAC. I feel that GAC is only for shared assemblies and we should not cluter it with anything else. But before making a decision on that I want to confirm that .NET framework does not support it. If .NET framework does support it we might as well add such a feature.

Here is the argument from the developer. Let me know your views.

As we move forward with the XXXXX.Application.Framework, class libraries are being shared among the various manufacturing disciplines. It's unmanageable to have the configuration entries for the various dlls stored under the monolithic app.config of the entry assembly (e.g. foo.exe.config), especially since these dlls may plug into an unknown number of executables which would all now have to know intimate configuration details and break encapsulation as a result.

As part of the XXXXX.Application.Framework using .Net 2.0 / EnterpriseLibrary, we've provided a consistent way for developers to use separate configuration files per assembly and have made it the default with format of <assembly>.config located in the same folder as the assembly itself. As an example, if assembly XXXXXX.dll needs configuration values it would expect to find them in file XXXXXX.dll.config located in the same folder as the XXXXXX.dll itself. We found it met developer's expectations if the standard was to put the assembly config file in the same folder as the assembly itself. This works well for both client and web server deployments, where you may not know a consistent absolute path location. This is pretty easy to achieve normally but is complicated when the assembly is deployed to the GAC.

Since some of the assemblies are going to be used widely by different groups on client PCs it makes sense to deploy these to the GAC since this is the scenario that the GAC was designed for. In general, the GAC works great with the exception that it's sometimes difficult to deploy our files there and the configuration file location issue. While we could have 2 different policies on config file location (if not GAC then local folder, if GAC then absolute path), it get's messy and hampers code re-use where the assembly might be deployed to both client and web servers. Best would be if we could use the same policy for everything and just always deploy to the assembly folder, wherever that may be, GAC or non-GAC.

We do have a way to deploy config files to the same folder that GAC assemblies live in using the current application. It's a little painful and I have to make assumptions about where the GAC is located which could be a problem in the future as this location could vary (for example, differences in GAC location between 1.1 and 2.0). The config files work just fine once they are there, the only trick is finding it and making sure that the assembly itself get's there first.

The purpose of this enhancement was simply to streamline the process of adding config files to the same location as the assembly files that they go with. While directed towards GAC deployments, this could be useful for situations other than GAC or even config files. At it's heart it's a request to "slave" one file to another - deploy file Y to the same location as file X, wherever X is deployed for a particular package.

A little long winded but that's the background on why this request was made. It's not a science experiment but rather just one more attempt to establish consistency among manufacturing developers where it was lacking previously.

Well, based on the web site above it is obviously possible to place the config files in the GAC. I'm not sure I would like doing what you are proposing, but if you think there is no alternative then I can see no reason to stop you. I'm not saying I can think of a better alternative, just that it doesn't feel right :)

/- Sam Judson : Wrox Technical Editor -/