EntLibConfig unable to open app.config from QuickStart samples

Topics: Pre-release discussions
Jan 31, 2007 at 5:09 PM
Edited Jan 31, 2007 at 5:51 PM
Standalone EntLibConfig unable to load app.config from QuickStarts samples, that use their own ("in-project" version 2.0) of Microsoft.Practices.EnterpriseLibrary.
Is there any quick workaround for this?
The tool is great and using it for exploring existing samples would be extremely helpful.

Thanks in advance,
Jan 31, 2007 at 6:42 PM
Hi Victor -

The standalone config tool searches in its own directory for the EntLib assemblies. If you have multiple versions of EntLib (eg one strong-named, one not), you need to use a version of the tool that contains the same set of assemblies. The config tool source is included in the source tree, so if you run BuildLibrary.and CopyAssemblies.bat you will get a copy of the tool in your bin directory that can open the QuickStarts.

Since you can't have multiple copies of Visual Studio installed, we came up with the "assembly set" concept to support this scenario within Visual Studio - this is documented in the release notes.

Jan 31, 2007 at 7:41 PM
Tom, thanks a lot!
This helps.
And thank you for the great tool. Now EntLib really makes sense. ;)

One note (not a big deal, but just for you to know).
At first I've installed src into original directory "C:\Program Files\Microsoft Enterprise Library 3.0 - January 2007 CTP" trying to keep related things under one roof.

Attempt to build the library gives the following fatal error:
Jan 31, 2007 at 8:41 PM
Thanks Victor. We're aware that there are a number of situations where you can run into problems with path names greater than 260 characters. The reason the default source code extract directory is c:\EntLib3Src rather than something like "C:\Documents and Settings\username\My Documents\Visual Studio 2005\Projects\Enterprise Library 3.0" is that we want to minimize the likelihood of paths that break the bank, but we know this isn't a perfect solution.

We're considering shortening the assembly names (not the namespaces), eg Microsoft.Practices.EnterpriseLibrary.Logging.Configuration.Design.dll could become EnterpriseLibrary.Logging.Design.dll. That would help a bit, but as you've discovered the biggest issue is actually resource files in the obj\debug folder. Unfortunately that insanely long filename wasn't actually chosen by us - the C# compiler generates it using a combination of the default namespace, the physical file path, and the original name of the resource. We're looking into options for dealing with this, but unfortunately we can't change the compiler's habits.

Not that this is any consolation, but we can't believe that this is still an issue in this day of age either ;-)