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.