unable to initialize the Enterprise Library Configuration Editor

Topics: General discussion
Sep 5, 2007 at 2:24 PM
I installed EL3.1 May edition, replacing EL3.1 April edition. I put all the original delivered DLL's into the GAC. When I open any solution from the Quick Starts and then right-click on the app.config and select Edit Enterprise Library Configuration, an error message box pops up saying:

Unable to initalize the Enterprise Library Configuration Editor.
Could not load file or assembly 'file:///C:\EntLib3Src\App\Blocks\bin\Microsoft.Practices.EnterpriseLibrary.Configuration.Design.UI.dll' or one of its dependencies. The system cannot find the file specified.

I checked C:\WINDOWS\Assembly\ and I see Microsoft.Practices.EnterpriseLibrary.Configuration.Design.UI.dll is in the GAC, so why the error? Can't EL3's config tool handle having things GAC'ed?
Sep 5, 2007 at 5:30 PM
Hi,


I checked C:\WINDOWS\Assembly\ and I see Microsoft.Practices.EnterpriseLibrary.Configuration.Design.UI.dll is in the GAC, so why the error? Can't EL3's config tool handle having things GAC'ed?


In this case, the answer is no. The VS integrated editor is designed to work with different versions of the assemblies (e.g. the unsigned binaries, the default binaries signed by MS, binaries signed by a different organization, etc), and each set of assemblies, called configuration sets, is read from the disk from a location specified in the registry.

Quickstarts specify that the editor should use the unsigned binaries through a property in the solution, so even if the GAC'ed signed binaries were used by the configuration editor they wouldn't be the ones needed here. My bet is that you haven't built the blocks' sources yet, so the configuration set in the registry is pointing to a folder that hasn't been populated with the unsigned binaries; running the 'BuildLibraryAndCopyAssemblies.bat' batch file from the source folder should take care of this.

Hope this helps,
Fernando
Sep 5, 2007 at 7:21 PM


fsimonazzi wrote:


In this case, the answer is no. The VS integrated editor is designed to work with different versions of the assemblies (e.g. the unsigned binaries, the default binaries signed by MS, binaries signed by a different organization, etc), and each set of assemblies, called configuration sets, is read from the disk from a location specified in the registry.

Quickstarts specify that the editor should use the unsigned binaries through a property in the solution, so even if the GAC'ed signed binaries were used by the configuration editor they wouldn't be the ones needed here. My bet is that you haven't built the blocks' sources yet, so the configuration set in the registry is pointing to a folder that hasn't been populated with the unsigned binaries; running the 'BuildLibraryAndCopyAssemblies.bat' batch file from the source folder should take care of this.

Hope this helps,
Fernando
{quote}

Running BuildLibraryAndCopyAssemblies.bat worked.

May I be the 1,234,567th person to request that this tool be delivered in a more works-right-out-of-the-box manner in the future, similar to how strong-named binaries are delivered and ready to be GAC'ed?
Sep 5, 2007 at 8:09 PM
Hi,


May I be the 1,234,567th person to request that this tool be delivered in a more works-right-out-of-the-box manner in the future, similar to how strong-named binaries are delivered and ready to be GAC'ed?


While I agree this can be a source of pain and it's poorly documented, this mechanism usually "just works" out of the box. The main installer will register the configuration set for the binaries to the install folder, which will be the default (so when editing configuration files for projects referencing the right configuration set will be used), and the source code installer will both register an additional configuration set pointing to the expected location for the binaries built from the source and build these binaries unless explicitly indicated otherwise.

Here's a post from Tom Hollander that provides more information about this mechanism http://blogs.msdn.com/tomholl/archive/2007/04/19/avoiding-configuration-pitfalls-with-incompatible-copies-of-enterprise-library.aspx. Hopefully this necessary information will be part of the install bundle next time.

Regards,
Fernando