Follow our journey as we reinvent business software

How I solved the problem of DLL’s being removed during WSP uninstallation

Lawrence Cawood

I ran into a problem a few weeks ago that took quite a bit of work to sort out, so I thought I’d share my findings with you guys.

WARNING: This post contains the words ‘WSP’ and ‘assembly’ many, many times.

I had a few different web parts that each had their own WSP as they are sold/deployed separately and are not related. I also had a ‘common’ assembly that was referenced by each of these web parts.

My first task was to package this common assembly so that it could be deployed with each web part, so I simply told (demanded?) Visual Studio to include the common assembly in each WSP. So now I had a bunch of WSP’s each containing a copy of the same common DLL. Would I be able to install these WSP’s without conflicts?

Yes. Lo and behold SharePoint installed my WSP’s and common assembly to the GAC just fine. I’m not sure if it overwrote or simply ignored the existing common assembly but it worked nonetheless — one common assembly referenced by multiple web part assemblies.

But I now had another challenge: if someone uninstalls one of the web parts, it would remove the common assembly from the GAC, breaking the remaining web parts that reference it. I tested this theory and indeed that is what happens.

Now I missioned trying to come up with a solution to this, and my searches all came up with the same suggestion: you need to create a separate WSP for your common assembly so that it doesn’t get removed when you uninstall your web part. I considered a couple of other ideas:

- Loading the assembly into the GAC programmatically (i.e. not via a WSP). I decided against this when I realised that I would have problems deploying to multiple servers in the farm, permissions etc. Best to leave that to SharePoint.

- Creating multiple versions of my common DLL so that each WSP would reference its own separate common assembly. I decided against this due to the nightmare involved with maintaining multiple versions of the same DLL. Deploying updates would be a major headache, and it’s just a messy solution.

- Moving the common code to each web part and scrapping the idea of a common assembly. Problem is, it was a very complex assembly with thousands of lines of code. Not having this as a common assembly would be maintenance hell and would make versioning really difficult.

I eventually settled on the idea of deploying the common assembly via a separate WSP just like the wonderful internet people suggested, which unfortunately presented yet another challenge…

I was using the popular SharePoint Solution Installer from CodePlex to deploy my WSP’s, but it only accommodated a single WSP as part of its standard functionality, and I had two of them to install: my web part’s WSP, and my common assembly’s WSP. I didn’t want people to have to go through two full installations (i.e. run two EXE’s) just to install a web part, so I decided to modify the SharePoint Solution Installer to install both WSP’s as part of a single installation (one EXE).

Some hacking was necessary, so I got to work modifying the Installer to first install my common assembly’s WSP, and then continue with its standard installation procedure of deploying my web part.

A couple days later and the end solution works like a bomb, so now my common assembly is deployed independently of the web parts that reference it.

The details of how I modified the Installer to do this are too complex to post here, but I just wanted to pass this general info on to anyone out there who is stuck with this same problem and pondering possible solutions.

Happy SharePointing!

Share twitter/ facebook/ copy link
Please enter at least 3 characters 0 Results for your search

May we suggest an author?

Lawrence Cawood