Tuesday, July 5, 2011

DLL configuration in a separate XML file

Ok, maybe its just me who does not like keeping all the settings of a library in a super-duper huge .settings file because I find this complicated to manage and troubleshoot. I like when I go to environment application folder, sort the files by type, locate the aspect I wonder and open the config file related to the environment.

So for one item I had to go with the block of settings extracted into a separate XML file. Here is some code:

* Settings.Mode contains current compilation mode (like development, staging or whatnot).

Looks simple enough except for it does not work.
First thing here to be surprised is the name of a class ExeConfigurationFileMap. Why is this an EXE configuration map? Will it work for DLLs? MSDN was silent and just outlined that the executable configuration file can be retrieved by a custom path. The answer is YES though, so it is a relief.

Not too much information I was able to find regarding the topic of WHY this fails with nasty exception


An unexpected error occurred in 'ClientConfigurationHost::Init'.

Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.InvalidOperationException: An unexpected error occurred in 'ClientConfigurationHost::Init'.


And stack trace was not telling what exactly failed and why. Even googling this exception did not clarify much. Fortunately, when I checked the file path which is to go to ExeConfigurationFileMap initializer:


file:\\C:\\Path_To_Project_Folder\\bin\\dependencyresolver.development.cfg.xml

Even though this is a perfectly valid file Uri scheme, ExeConfigurationFileMap initializer is not able to resolve this mapping. Thanks to this post (where the person posted an issue and then posted a resolution himself), the code turned into the following:

And the file path turned into the following:

C:\Path_To_Project_Folder\bin\dependencyresolver.development.cfg.xml

The -under-the-hood- part of this issue can be probably discovered by digging into reflected .net code, but I felt like it was better to frustrate a little about it...

No comments:

Post a Comment