Visual Studio Extensions for Windows SharePoint Services (VSEWSS) Error: Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information


One error you may see when packaging solutions with VSEWSS is:  Microsoft.SharePoint.Tools.Utilities.VSeWSSServiceException VSeWSS Service Error: Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.  Like most error messages from VSEWSS, there is not enough information provided to resolve the issue, so I hope to save you some time by providing a workaround that will permanently fix this problem. 


When VSEWSS packages your solution, it uses reflection to enumerate the packaged assemblies.  It works fine until it encounters an assembly that implements an interface that is defined in another assembly as is often the case in the Microsoft.Practices.* assemblies.  I am unsure of exactly why, but the extensions are unable to resolve the dependent assemblies.  To work around the issue, you can copy the dependent assemblies to the GAC, but I don’t think this is the optimal solution and doing so will cause pain during development and debugging.  Another option is to copy the dependent assemblies to the VSEWSS service bin directory post build.  After trying this for awhile, and maintaining the script, I decided it would be much simpler to just copy all assemblies in my solution to the VSEWSS service bin directory on post build.  Here is the script:

@rem======================================================================
@rem
@rem This script copies assemblies to the VSEWSS bin directory
@rem to eliminate the packaging type load exception that occurs
@rem when an interface is defined in a separate assembly.
@rem
@rem usage call $(ProjectDir)Scripts/CopyAssembliesToVSEWSSBin.bat $(TargetDir)
@rem
@rem======================================================================

@echo off

@echo ========== Locating VSEWSS bin directory ==========
@set vsewssbin=%programfiles%\Microsoft SharePoint Developer Tools 9.0\svc\bin
if not exist “%vsewssbin%” set vsewssbin=%ProgramW6432%\Microsoft SharePoint Developer Tools 9.0\svc\bin
@echo VSEWSS bin: %vsewssbin%

@echo ========== Copying assemblies to VSEWSS bin directory ==========
@xcopy “%1*.dll” “%vsewssbin%” /R /Y


To use the script, create a bat file in your project and call it from a post build event. It does take 64-bit installations into account, and it will also work on your Team Build server.

Comments (6)

  1. Geno - USA says:

    This is very helpful advice – it worked in a situation where the GAC deployment did not.

  2. Raminder Ahlawat says:

    I have been trying to fix this issue for daysss. I ended up deploying my solutions by a clugged up way.

    Tried to google for an answer. Again no luck. On Bing however this is the forth article, and BINGO, the deployment now works like a charm

  3. Evgeny says:

    Thanks, You post save me a lot of time

  4. Aadil says:

    You are genius. Thanks a lot!!!!!!!!!!!!!!!

  5. Dathan says:

    You might also want to check the properties on the additional libraries you are referencing. This issue can occur in the following situation: you add a reference to a 3rd-party or other external .dll before you add it to the GAC, in which case Visual Studio may set the “Copy Local” property to true. In this situation, if the .dll is also already deployed to SharePoint via the GAC or directly at deployment time, VSeWSS may begin to intermittently raise this error because (I believe) it then tries to also de-and-re the 3rd party lib in the GAC.

    Punch line: make sure Copy Local is set to false for any libraries that are not specifically part of your project development.

    Regards,

    Dathan Liblik

  6. hossein says:

    Thanks a lot John, I shared your post on my blog.