The reason for needing the config file to be named for the exe and not the dll is because of where the CLR is hosted/loaded.
Remember that any application that uses the CLR such as a .NET app which uses it right off the bat or an unmanaged one that calls managed code has CLR is hosted within that applications memory space and when the configuration data for the CLR is loaded and applied, it is done within the scope of the application and thus the need for the config file to be named for it.
Another way to think about this is that if you could specify the runtime for each dll individually, it would theoretically be possible to have a single application host multiple CLR runtimes... something that thankfully isn’t possible due to the great potential for break downs.
Instead, it’s all one version or another and while 2.0 can use assemblies that were compiled for 1.0, 1.1 and 2.0... it isn’t always able to do it as well as the versions they were compiled for and this is why when a .NET application (or assembly) starts up, it asks to be loaded in the CLR version it was compiled for (or what is specified in the appropriate config file) and if it is unavailable and no rules prohibit it, will be loaded into a higher version.
My guess is that the reason this hasn’t failed before is that the machines you’ve run it on in past had the 1.1 framework available, while the one you are having the problems on only has 2.0.
I agree that it is an odd way to name files but it is the way. Not long ago I built a C# library that looked like a COM component for a co-worker to use in a VC6 application he was working on and after many problems of trying to use the web service it provided he finally asked what was wrong and after some investigating we found that he hadn’t renamed the config file as needed, it started out as YourAppNameHere.exe.config, but after we changed it all worked great.
P.S... sorry for the above... book.
|