6

For a while now, me and my team having been having an issue where when we try and deploy a project we very frequently end up with the error

Error occurred in deployment step 'Add Solution': Error: Cannot add the specified assembly to the global assembly cache: Microsoft.Practices.ServiceLocation.dll.

We get around this by restarting IIS and once we do the project will deploy fine. But now our project is getting big and deployment take a long time and it is becoming incredibly annoying having to deploy twice.

So, we have decided to tackle this issue and clearly failed. Thus, I have turned to the internet and I'm hoping someone out there might know why this happening and how we can prevent it in the future.

2
  • Try IISReset and then deploy, it work like a charm
    – user45051
    Commented Aug 12, 2015 at 18:36
  • IISReset + Visual Studio restart helped me.
    – Raf
    Commented Oct 24, 2018 at 6:22

2 Answers 2

3

I can think of a few things, but try these for starters :

  • Verify that your development environment and your other SharePoint servers have the exact same version of the Enterprise Library installed
  • Check each WSP that your team is creating to make sure that it is not bundling an older version of the DLL in your WSPs Library as well. You may need to manually inspect each WSP by renaming them to .CAB and then browsing the content in Windows Explorer
  • Make sure that you do not have an older copy of that DLL anywhere on your dev machines or on your sharepoint servers. People are notorious for manually copying troublesome DLLs to the /bin/ or /_app_bin/ of the web application
  • If you have other older WSPs that are deployed to that farm make sure that they do not reference and include the older version of the library
  • If you have a build server that checks and builds your WSPs then do all of the above on that server as well
  • If you are building your Enterprise Library from source, be sure that you have key for it and it is strong-named.
3

I'd recommend that you put:

  • the Microsoft.Practices dlls into a seperate WSP (MSP.WSP)
  • set your WSP to depend on MSP.WSP
  • Deploy the MSP.WSP

Now you don't have to retract/deploy these standard dlls every time you deploy you package. And maybe also split you package into smaller WSPs depending on when you need to upgrade them.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.