Why Visual Studio 2010 “Deploy” is not a reliable test for your solution

We’re mid-way through building our first commercial SharePoint 2010 system, We’ve been at it for a few months, but are starting to shift all our software over to RTM, and there are some quite lovely gotchas to be aware of.

Visual Studio 2010 is a fantastic product, and a great improvement over VS2008, but if you are not careful it can lead to lazy development.

The main lesson of the day is do not rely on Visual Studio 2010 “Deploy” to test your packages!

There are a number of reasons why this method is unreliable from a testing perspective:

  1. Deploys to existing site collection
  2. Automatically activates your features
  3. Automatically resolves conflicts

Challenge #1 Deploys to existing site collection
This is quite critical (and in many ways, rather annoying) that Visual Studio 2010 will deploy to a Site Collection. This of course means that if you have deleted your site collection then you have to deploy the old fashioned way (typically using STSADM or PowerShell).

But how many developers in the coming months are going to end up shipping WSPs to their test teams with broken site collections?

I know it sounds stupid, but I’ve even done it myself .. deleted features from the Package, done a VS2010 deploy and everything works fine. Until you re-create your site collection and there is a Feature ID in the onet.xml that doesn’t exist anymore.

All good common sense stuff .. but make sure you are regularly re-creating your site collections!

Challenge #2 Automatically activates your features
This is another great feature, but can seriously break your builds (or lead you to produce incomplete builds if you aren’t careful!)

Central Administration is a great one here. If you are buidling features for Central Admin (say new admin pages or custom action features) is quite common (nay, useful) to set your Features to AutoActivateInCentralAdmin=”TRUE”. Yeh .. if you have your VS project pointing at the Central Admin URL then this will break your deploy function!

You see .. VS will “deploy” your WSP (which auto-activates the features in Central Admin) .. then VS tries to activate them AGAIN. This causes the deployment process to crash, so you have to kick VS back into non-activation mode.

This even creates challenges in your Site Collection (don’t forget Challenge #1 up above). VS2010 kindly activates all of your features for you … yes .. ALL of them. You don’t get to choose which ones get auto-activated, and unless you order them correctly in the package then you can’t explicitly control which order they are activated in either.

So you have another problem where your dev build is happy as larry, but when you hand the WSP to your testers they moan that activation dependencies are breaking, or certain features aren’t showing up!

Challenge #3 Automatically Resolves Conflicts
Now .. don’t get me wrong .. for a dev environment this is GREAT … it means we can roll things in, out and in again all day long without having orphaned files or worrying about overwrites.

But again, it creates that “non-realistic deployment” scenario where developers roll out their WSP for the 20th time .. not realising that when you do the same thing in your test environment you don’t have Visual Studio sitting in the background doing a load of resolution conflicts.


I suppose the lesson of the day is be careful!

Think about where your WSP is going to end up, who is going to be deploying it, and what environment it’s going to live in.

  • Jeremy Thake

    I'm with you on this one Martin, I'm already writing an add-in for #VS2010 to create powershell scripts that make this more portable and not so reliant on VS2010. Great for a dev box, lousy for anything else. can see developers just handing wsp's around with no instructions.

    My presentation on ALM with VS2010 and SP2010 might be of interest to you too…
    http://wss.made4the.net/archive/2010/04/16/introducing-sharepoint-2010-sp2010-development-to-alm-tfs2010-screencast.aspx

  • Martin Hatch

    Absolutely, but wanted to raise the issues of the actual "Deploy" mechanism in Visual Studio being very different to someone using the Deploy button from Central Administration.

    Visual Studio can do a lot of additional processing that developers need to be aware of!

  • Anonymous

    I think how you choose to structure your solution goes a long way to aid the deployment process.

    I would suggest that multiple projects being packaged independantly during dev may be a good approach, only single package for final build.