views:

5648

answers:

2

I am currently getting the following exception while trying to use the Enterprise Library Validation Application Block:

An error occurred creating the configuration section handler for validation: Could not load file or assembly 'Microsoft.Practices.EnterpriseLibrary.Validation, Version=4.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040) (C:\Documents and Settings\My Documents\Visual Studio 2008\Projects\Testers\TestProject\web.config line 12)

I know what the exception is trying to tell me, but I can't figure out how to fix it. I have only ever installed one version of the Enterprise Library, and this is it (4.1.0.0), so I don't see how it could be finding the wrong version, so I imagine it is then a dependency problem. I have included the "Common", "Validation" and "ObjectBuilder2" DLLs from the Enterprise Library 4.1 as references in the project, so I'm not sure what else I'm missing. The documentation certainly seems to indicate this is all I need.

Is there any way to track down what the dependency problem is?

If it helps, I am trying to use the Enterprise Library Configuration Tool to create a Validation Application Block rule set for validation of data in an Entity Framework entity. I am using ASP.NET MVC in Visual Studio 2008.

Thanks for any assistance/direction you can provide,

Chris

+2  A: 

Turn on Fusion logging and see what assembly is being bound at runtime.

Hanselman had a post recently that should be helpful in enabling logging and examining the output.

http://www.hanselman.com/blog/CommentView.aspx?guid=3654c8f3-c5c3-4dee-a01f-c9a8da3ef2fa

Another important distinction to make is that references that are added to the project are compile-time references and don't affect the way that code is bound at runtime other than to specify a strong name if a strongly named assembly was used. In order to find out what is happening at runtime you need to look at the binding logs. The log should show you all of the attempts that the runtime makes at locating the assembly. If the assembly is not in the bin directory along with your exectuable, it is most likely looking in the GAC and finding a version that it does not expect.

Note that the compiler DOES NOT use the GAC when referencing assemblies. So most probably you have a different version used as a reference in the project than you have installed in the GAC.

Also, it is very easy to find out what version you have installed in the GAC by looking in C:\Windows\assembly using Windows Explorer. The version that is specified in your error message will be the version that was referenced during compilation. If these versions don't match this could be your problem, assuming that Fusion is indeed looking in the GAC (which will be evident by looking in the Fusion log).

dnewcome
Thanks for the pointers. I eventually realized that due to the way I was doing references it was pulling in the default version of the DLL instead of the newer one. I foolishly thought I had to build the DLL myself instead of using the pre-built binary in the package, so obviously the token didn't match the one I was setting. I sorted out the installation with Enterprise Library so it was using the DLLs built by Microsoft and everything was happy. I'll look into using fusion though, it sounds like it would have helped me out in tracking this problem down faster. Thanks!
Chris
A: 

Tom Hollander, one of the designers of the Enterprise Library, wrote an interesting article about this on his blog: Avoiding configuration pitfalls with incompatible copies of Enterprise Library. A must read for everybody, starting with the Enterprise Library.

Steven