Visual Studio 2008 add-in fails when referencing the EntLib 4.1 indirectly

Topics: Logging Application Block
Mar 31, 2009 at 8:31 PM
I am writing a Visual Studio 2008 Add-in. This add-in uses an assembly (call it common.dll) that itself uses the Enterprise Library 4.1. The common.dll assembly is installed in the GAC. When I try to load my add-in and a call to a method inside common.dll is made, which in turn calls the Enterprise Library, the following error occurs. 

Could not load file or assembly 'Microsoft.Practices.EnterpriseLibrary.Logging, Version=4.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified.

I have been trying to figure out what is going on. The only thing I can think of is that somewhere in the dependency chain there's an invalid, or misconfigured, assembly. But I have tried to figure out which to no avail. The same common.dll is used in another application and that works fine. Even custom work item controls work fine. Any ideas?
Apr 1, 2009 at 9:36 AM

Does the other application which uses the common.dll runs on the same machine?  Does it have a reference to the Logging assembly? If it has, try referencing it from you add-in as well.

Sarah Urmeneta
Global Technology & Solutions
Avanade, Inc.
entlib.support@avanade.com

 

Apr 1, 2009 at 6:36 PM
Yes and no, at least not directly. There's a reference to the *Logging* assembly through the *common.dll*.

At the end of the day the problem is that any assemblies that are referenced by strong name in your configuration file should be added to the GAC, at least this is my experience when writing add-ins for Visual Studio 2008. In all other cases where I use the EntLib for custom applications and web sites I never ran into this problem. It seems to be that there's something in the way add-ins are handled.

To provide more information, I am also not deploying my add-in in the typical C:\Users\<username>\Documents\Visual Studio 2008\Addins (Windows 7). I only place the .Addin file there but deploy the assembly elsewhere. So, I don't know if this adds to the problem.

In any case, I managed to get it all working by making sure that all referenced assemblies in the configuration file are registered in the GAC. That does the trick. So, if anyone is having a similar problem just make sure you review your configuration file.