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.

SharePoint 2010 released to manufacturing! Release Schedule announced

Breaking news from the Microsoft SharePoint Team Blog as SharePoint 2010 has been released to the manufacturers.

What does this mean for those waiting to get their hands on it?

SharePoint 2010 Release Schedule

17th April 2010 (today) - RTM

27th April 2010 - Volume License SA (Software Assurance) available for download

1st May 2010 - Volume Licensing available through Microsoft Partners

12th May 2010 - Official global launch to businesses

You can find more details from Jeff Teper, the Corporate Vice President, SharePoint Server here.

How my Module feature broke the Publishing Feature

So .. there I was in SharePoint 2010, working on a new corporate website in Visual Studio 2010.

We decided we needed some image assets to be provisioned, so I decided to make use of some of the new features of VS2010 and created a "Module" SharePoint Project Item.

I added my images, telling to to deploy to RootWebOnly and setting the path as PublishingImages, everything a good SP dev should do...  or so I thought.

Deployed my solution .. blam .. Site Collection dead. I fired up the (quite excellent) ULS Viewer which told me the following error messages:

'Failed to create the 'Images' library.'. Exception was: 'Microsoft.SharePoint.SPException: A list, survey, discussion board, or document library with the specified title already exists in this Web site.

Publishing Feature activation failed. Exception: Microsoft.SharePoint.SPException: Provisioning did not succeed. Details: Failed to create the 'Images' library.

Now this was instant brown trousers time ... the Publishing Feature was broken!!! (or so I thought).

What had actually happened was brain stunningly simple. You see .. Visual Studio had kindly placed my new Module item into a Site Scoped feature...

The Publishing Feature is Web Scoped...

Now .. hopefully the sharper reader will already have realised the predicament. As I explained in an earlier blog post (onet.xml order of execution) Site Scoped features will activate before web scoped features ... more accurately my Modules feature is trying to place my images into /PublishingImages/ before the document library has been created!!

What it actually did was create a folder in the SPWeb (yes .. you can have SPFolder objects directly within an SPWeb .. you don't need a document library) so when the Publishing feature came along the URL "/PublishingImages" was already in use!

I created a new Web scoped feature for my images module and re-deployed ... everything is now working. (the publishing feature activates first .. creating the image library ... and my images are placed inside it).

*sigh*

Another one to put large and clear on the blackboard of experience!

Controlling the order of Feature Activation in Visual Studio 2010

(Note - this behaviour was observed in VS 2010 RC .. I haven't tested yet in RTM)

One of the most challenging things I've had to deal with in a long time is trying to work out how to get Visual Studio 2010 to activate my Fields feature before it tries to activate my Content Type feature :)

First I was (obviously) getting errors that the field didn't exist (because it couldn't find the Field that the FieldRef was pointing at).

Next I tried adding a Feature Activation Dependency, hoping that Visual Studio would intelligently activate them in the order of the dependencies that I setup ... WRONG ... I am now getting errors saying it cannot activate because the dependency is not active (doh!).

Finally struck upon something .. going to the Package .. the features were being activated in the order they appeared in my VS 2010 Package item.

Unfortunately there is no "move-up", "move-down" or drag and drop re-ordering, so I had to remove all of the features from the package and then put them back in the correct order of activation.

UPDATE
It seems there ARE move-up / move-down buttons, but they don't stick to the scrollbar so if you scroll down (to the bottom of the package) you can't see them anymore. Anyway .. yes you can re-order them .. but you'll maybe find this slightly more difficult if your features are at the bottom of the package list.

Slightly frustrating, but glad it's all working now!

Speaking at the SharePoint Evolution Conference, London

For those who don't know, the SharePoint Evolution Conference 2010 in London is fast approaching. It's 3 days of SharePoint antics with over 70 sessions dedicated to SharePoint professionals and the imminent launch of SharePoint 2010.

I will also be speaking in the Community Track (COM109) on Tuesday 20th April, 2pm-3pm, presenting alongside Kelly Harrison from the RNIB about some of the challenges and lessons learned from building a fully accessible SharePoint system.

It looks to be a really great event, with over 55 expert speakers, from both Microsoft and other well-known companies. Find out more reasons why you should attend and hopefully I'll see you there!