Geeks With Blogs

Fringe SharePoint Continued

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!

Posted on Sunday, February 19, 2012 8:25 PM SharePoint , TFS , Development , Web Parts , ALM | Back to top


Comments on this post: 'To Sign or not to Sign' that is the question!

No comments posted yet.
Your comment:
 (will show your gravatar)


Copyright © juanlarios | Powered by: GeeksWithBlogs.net