A while back I was helping a client upgrade SharePoint 2007
code to SharePoint 2010 and I came across this interesting problem. I was
working web parts that were created in Visual Studio 2008 using WSPBuilder extensions.
The first order of business was to convert them to Visual Studio 2010 templates
instead of using WSPBuilder 2010 extensions.
Why Use Visual Studio 2010 templates?
There are two main reasons I highly recommend using Visual
Studio 2010 templates instead of using WSPBuilder 2010 templates.
1. WSPBuilder 2010 is still in beta! Although it
was really convenient to use WSPBuilder 2007 for SharePoint Customizations
instead of using the alternative extensions for Visual Studio, VS2010 templates
are superior and integrated quite nicely into all the development tools you
would use in VS2010. I don’t necessarily like using Beta software or tools for
clients or Production environments.
2. VS 2010 Extensions integrate nicely for Team
Builds and WSP generation and deployment. One nice enhancement in VS 2010 is
that you are able to use TFS for Team Builds. Instructions for Setting up TFS
with the appropriate dependent DLL’s is pretty common now but not quite as
clear as it was when I first was building the TFS environment. We actually
tried to use WSPBuilder 2010 and setup TFS to build and deploy WSP environments
but it proved quite difficult (This topic is maybe better suited for another
post).
Interesting Problem
Once switching over to VS2010 Templates we ran into
interesting issue. In SharePoint 2007 you could deploy a web part to a targeted
Web Application and set CAS (Code Access Security). Some of you might be
saying, “so what? It’s the same in
SharePoint 2010!” Well, yes and no, you
can still deploy to a targeted web application and set CAS but the key
difference is that VS 2010 needs the
Assembly to be signed. This became a huge problem for the client I was
working with, because they referenced unsigned assemblies. A signed assembly
simply means that it is trusted and since it is referencing ‘untrusted’
assemblies Visual Studio could not package the WSP.
There are two ways you usually use references. You deploy
them with the packaged WSP or you reference them and don’t copy them in. In
this case we had multiple customizations deployed at the Web Application level
so all the referenced assemblies resided in the Web Application Bin folder and
even though they were not packaged with the WSP, they were still being
referenced and unsigned. No matter what we did VS2010 would not package the web
parts.
What can I do?
There is really no way around this issue. Interesting
enough, this is not a SharePoint 2010 limitation. If you take the SP 2007 WSP’s
with unsigned assemblies they will still deploy and work in a SharePoint 2010
environment. The problem is, you don’t want to be working with SP 2007
solutions in visual studio. You will need to eventually work (develop, upgrade
and manage) within a SP 2010 environment and they will need to be upgraded.
<! 1. Sign the referenced assemblies – If you simply
sign the referenced assemblies and then the web part assembly you will be able
to package and deploy the WSP. This might be a bit of an undertaking, and it
was for us. Hundreds of DLL’s, and multiple projects. I can also think of
situations where you don’t have control over a 3rd party dll.
<! 2. Use WSPBuilder 2010 – you can still deploy
unsigned assemblies to the Web Application level. Like I said this is not a
SharePoint 2010 restriction. WSPBuilder will package your solution but to do
take not that it will still warn you that it is packaging an unsigned assembly.
Even though it doesn’t like it, it will still do it.
Conclusion
So what can we take away from all of this? Well, there is
absolutely nothing wrong with signing an assembly. In fact every TFS expert
tells me that every assembly should be signed, period! The advantages of
leveraging TFS for team builds and more importantly deployment to your
environments is a clearly a better trade off than using unsigned assemblies.
To Sign! That is the Answer!