Topics: Enterprise Library Core
Oct 12, 2007 at 8:40 PM
I have a question about packaging up the EntLibConfig.exe application. Essentially, I need to know if there are any dependency files or helper files that I should/need to include when I package the exe with our setup. Can anyone field this off the top of their head?

Roger Sutter
Oct 12, 2007 at 9:24 PM
Ok, I think I solved this one. If you look in the ..\src\Configuration\Console\bin\Debug folder, it lists all the files that it references. Ergo, I'm assuming these are the files that I need to include when I package EntLibConfig.exe.

If I am wrong, feel free to step in and correct me as I am fairly new to Visual Studio.
Oct 13, 2007 at 7:04 AM
The config tool requires just the following assemblies to run:
  • EntLibConfig.exe
  • Microsoft.Practices.EnterpriseLibrary.Common.dll
  • Microsoft.Practices.EnterpriseLibrary.Configuration.Design.dll
  • Microsoft.Practices.EnterpriseLibrary.Configuration.Design.HostAdapter.dll
  • Microsoft.Practices.EnterpriseLibrary.Configuration.Design.UI.dll
  • Microsoft.Practices.ObjectBuilder.dll

However with just this set of assemblies, it won't actually do anything useful, since the other .Configuration.Design.dll assemblies (which have dependencies of their own) provide the functionality to configure the individual blocks. Unless you have a very good reason not to, it's generally best to include the entire set of assemblies from the default bin directory.

Feb 20, 2009 at 9:14 PM
We are working on deploying Enterprise Library 4.1 to the GAC (MS signed version) and are having issues with EntLibConfig.

We assumed that with all the assemblies in the GAC, EntLibConfig.exe can reside alone in some directory and still be fully functional; however after opening a .config file none of the block information is displayed.  fuslogvw doesn't catch any successful or unsuccessful load attempts of the EL assemblies, so it appears that EntLibConfig isn't even trying.  If we copy all the EL dll's (same signed version as in the GAC) into the same directory as EntLibConfig, all is well and fuslogvw shows all assemblies were loaded from the GAC.  We don't understand why the assemblies need to reside alongside EntLibConfig.

We would like an un-cluttered install of the config tool and more importantly, to understand why the assemblies need to be in the same folder as EntLibConfig when they are not being used.  Any feedback as to why this is and/or how to change it would be greatly appreciated.

Feb 21, 2009 at 2:36 AM
I believe that is defined by the EnterpriseLibraryConfigurationSet property of your solution.  Taken from Tom Hollander's blog:

"Things are a little more interesting if you are using the Visual Studio-integrated Configuration Editor, since you can't install multiple copies of Visual Studio. By default, the Configuration Editor will use the strong-named Enterprise Library assemblies. However it is possible to redirect the tool to a different set of assemblies on a per-solution basis. To do this, open a solution, select the solution root node in the Solution Explorer and then look at the Properties window. You should see a property called EnterpriseLibraryConfigurationSet. By default, this will contain the options "(Machine default)", "Microsoft Signed" and "EntLib3Src". Selecting "EntLib3Src" will tell the tool to use the assemblies from "C:\EntLib3Src\App Blocks\bin" for editing any configuration files in this solution. Note that we set the EnterpriseLibraryConfigurationSet to "EntLib3Src" for all of our QuickStart applications, since they are compiled against the source code projects. If you want to add, edit or remove the "configuation sets" or change the default, this information is stored in the registry in HKEY_CURRENT_USER\Software\Microsoft\Practices\EnterpriseLibrary\ConfigurationEditor (for per-user settings) and HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\8.0\Packages\{488366a4-630c-4a0e-a6a2-b019cee13bea}\ConfigurationEditor (for machine-wide settings)."

blog link : http://blogs.msdn.com/tomholl/archive/2007/04/19/avoiding-configuration-pitfalls-with-incompatible-copies-of-enterprise-library.aspx

Sarah Urmeneta
Global Technology & Solutions
Avanade, Inc.
Feb 21, 2009 at 4:25 AM
Thanks for the reply.

I believe that applies to the use of the config tool as integrated with Visual Studio.  Our issue pertains to the use of the tool in the target environment after deployment.  However, we do have the EnterpriseLibraryConfigurationSet property set to "Microsoft Signed", which is our desired usage, so I don't think that can be the source of the problem.  Also, we can tell by using fuslogvw (in the deployed target environment when loading EntLibConfig.exe) that the assemblies being used are the MS signed ones; our problem is that this only occurs if the assemblies also exist in the same directory as the config tool...

Feb 22, 2009 at 5:06 AM
The config tool doesn't have any compiled in knowledge of the entlib DLLs. Instead, at startup it scans it's current directory looking for assemblies with the right attributes on them. That's why you're not seeing anything when the DLL's are in the directory - the list of files is empty, so it doesn't try to load anything. This is necessary because the tool is extensible; you can add additional configuration nodes easily by just dropping in a new DLL.

There's no supported way from managed code to scan the GAC, so we don't do that.

If you put the Entlib assemblies in the GAC, they'll be used at runtime. It's only the configuration tool that requires they be in the same directory.

Feb 22, 2009 at 5:28 AM
I understand; thank you very much for the explanation.