Enterprise Library 4.0 Config Tool Refuses To Load config

Topics: Enterprise Library Core, General discussion
Sep 19, 2008 at 7:33 PM
I have a config file that I modified using the Enterprise Library 4.0 config tool.  I added a custom exception handler that references one of my custom implementations.  I saved the config file and everything was fine.  Now when I open that config file using the config tool it gives me a configuration error at the bottom saying "Could not load [my assembly fully qualified name] or one of its dependencies.  An attempt was made to load a program with an incorrect format.  I have no idea what this is talking about since it didn't give me any errors when I first saved the config file.
Sep 19, 2008 at 8:33 PM
I also noticed this when I chose to add a new exception handler type.  I opened up the source code for the configuration console and saw that it occurs in TypeSelectorUI.cs. 
In OnBrowseButtonClick it looks like it loads the assmebly from a temporary file.
 Assembly assembly = null;
                    using (AssemblyLoader loaderHook = new AssemblyLoader(originalAssemblyFileName, referenceDirectory))
                    {
                        assembly = Assembly.LoadFrom(loaderHook.CopiedAssemblyPath);
                   
                        if (!this.selector.LoadTreeView(assembly))
                        {
                            DisplayMessageBox(string.Format(CultureInfo.CurrentUICulture, Resources.NoTypesFoundInAssemblyErrorMessage, assembly.GetName().Name, this.selector.TypeToVerify.FullName), Resources.NoTypesFoundInAssemblyCaption);
                        }
                    }
I changed loaderHook.CopiedAssemblyPath to originalAssemblyFileName and it worked.  Maybe this wasn't tested on Vista Ultimate x64?  I don't know how temp files work in Vista but the copied assembly path is a reference to some .tmp file and it had a problem loading that .tmp file as an assembly.
Sep 22, 2008 at 3:14 PM
Hi,

Can you provide more information about the issue? I'm a bit confused because your first post indicates that adding and saving worked, but your second post describes a different situation.

Were you using the stand-alone version of the tool or was this the Visual Studio version? What does your assembly look like? Is it built for 32 bit architectures, or does it have any dependency on 32 bit assemblies?

Try reproducing it with a new assembly with just the exception handler type. Does it still fail? I could only make it fail using the stand-alone tool by explicitly targetting x86 for my repro assembly.

Fernando
Sep 22, 2008 at 7:38 PM
Hi,
Basically the problem was everytime I tried to reference a custom type through the configuration tool I got an error saying that my assembly was in an incorrect format.  At one point I was able to add a custom exception handler through the tool and it worked fine.  Then a few days later I got the incorrect format error whenever I tried to reference a custom type that I built.  When I opened the source code for the config tool I notice that whenever the tool asks the user to reference an assembly for a custom handler, it doesn't load the actual dll, but rather a dll from the temp folder as you can see in the following code:
assembly = Assembly.LoadFrom(loaderHook.CopiedAssemblyPath);
That CopiedAssemblyPath references a .tmp file on Vista x64.  The attempt to load that .tmp file is whats throwing the incorrect format exception.  When I change the path to load from the actual path of the dll, rather than the temp file, it works fine.  I'm not familiar with temp files in Vista x64 so I don't know if that .tmp file is the actual assembly. 
FYI
I was using the version of the tool that was automatically built when I downloaded and installed enterprise library 4.0 from msdn.  I then rebuilt the tool using the source code that came with the install and found the bug.
Thanks 
Sep 23, 2008 at 1:20 PM
Hi,

I don't see how copying a dll file would render it unusable, regarless of the version you're using. I am using Vista Ultimate x64 and I've never seen this problem.

Can you try with new custom handler in a new assembly? Make sure this new assembly is targeted to "Any CPU". If this doens't work, and you can debug the tool, get a hold on the temporary file name and perform a binary comparison (FC.exe /B file1 file2 would do.)

Fernando