Beyond F5 deployment - my top 5 benefits of Visual Studio 2010 Tools for SharePoint

Having used the VS 2010 Tools for SharePoint for a while now, I thought it appropriate to stop and look beyond the headlines of F5 deployment/debugging and think about how some of the other aspects of the tools will change the way developers work. This post isn’t meant to be a walkthrough of the tools – other folks have already done that, and also I’m assuming many of you are now somewhat familiar with what the tools do. Rather, you should probably consider this post as ‘editorial discussion’. So, aside from the fact that “Visual Studio now builds WSPs”, here are some things I’ve been pondering – I’d be interested if you have any thoughts:

1. Possibility of global consistency for SharePoint developers:
   
   Personally, I’ve seen a ton of different approaches used on SharePoint 2007 development projects. When you think about WSPBuilder, STSDev, SPVisualDev, SharePointSUSHI, WSeWSS and MSBuild scripts as popular ways of structuring Visual Studio projects and building WSPs for SharePoint 2007, you start to realize just how much variation there is. Most would agree WSPBuilder was ultimately the most popular, but pretty much all of those tools provided benefit to 2007 development in some way. However, don’t you ever wish things were more consistent across SharePoint projects? So that when you moved to the next client/project where some work had already been done, there was no ramping-up time for how the VS projects were built so that you (and each new developer on the project) you could just focus on functionality? 
   
   I think the new tools may offer this. Sure there will always be variations (e.g. projects with the tools can still be structured differently, some folks will continue to use WSPBuilder/a “run-time file location” approach), but I’d expect this to be much reduced. That can only be a good thing IMHO.
   
   
2. Extensibility (e.g. productivity add-ons):
   
   One of the most impressive things about the 2010 tooling is how extensible it is. We’ve already seen the community produce fantastic add-ons and we’re still only in beta. The great thing about these extensions is that they compliment the MS tooling, so whilst they enhance the developer experience they’re all additive – the fundamentals are not changed, so the problem described in the previous point shouldn’t apply. Great add-ons so far are led by the Community Kit for SharePoint:Dev Tools (CKS:DEV) - I’m already at the stage where I can’t live without the ‘quick deploy’ capability of SPVSX (one of the components being merged into CKS:DEV at the time of writing). This gem accelerates your SP2010 feedback loop immensely by providing options to copy GAC/BIN assemblies automatically on a build, and copy uncompiled files (e.g. .ascx, .js, .css, images) to the SharePoint Root on save (similar to SPVisualDev if you ever used that). This is much faster than F5 deployment and frankly I think it will become the WSPBuilder of SharePoint 2010 development:  
   
    
   
   Going back to the extensibility in general, another favorite is the customizable deployment steps – so for example if you want to have a deployment configuration which tears down and reprovisions your site collection (e.g. because you are testing provisioning code), you can create such a step and include it.
    
3. Feature building/refactoring support:
   
   In SharePoint 2007 development, some of the community tools helped you build Features to a certain extent. Several had project item templates which would start you off with some default XML to get you started. However, when it came to refactoring Features, you were basically cutting and pasting lots of XML around with no support. I think it’s fairly common to have to do this in team development at some point - I’ve just gone through a major exercise of this on my current project, but generally in the same way that we refactor code, we refactor Features. What I like about the Visual Studio tools is that many things get fixed up as you move elements into different Features, and Features into different solutions. As examples, the following travel/get fixed up as you move things around without you having to modify XML as before:
   
   - Feature receivers
   - Feature resources
   - Feature properties
   
   
4. Solution building/refactoring support:
   
   So in addition to Feature factoring, consider Solution factoring for a moment. In SharePoint 2007 development, if you had 10 Visual Studio projects but didn’t want 10 .wsps (and why would you?), things got tricky. Effectively you needed to consolidate files in the SharePoint root (12 hive) of 1 or 2 projects, and build a .wsp from there – many teams were using this technique. My preferred solution was to use MSBuild for copying the files around on compile, but post-build events worked fine too. Either way, always a pain to set up though. One thing I love about the VS2010 tools is that you can graphically pick and choose what goes into each .wsp – in the image below, items in the left column are assets in the solution (i.e. in any VS project), and items in the right column are in the .wsp for the current VS project. I simply use the UI to add things in for each project – and thus I can factor my .wsps any way I want, very easily: 
   
   
   
   
5. Deployment Conflict Resolution
   
   My final benefit of the 2010 SharePoint project system is Deployment Conflict Resolution. This is ‘built-in intelligence’ for handling deployment conflicts, such as what to with an existing list on a dev site if it is being redeployed. Another example is the .webpart file which defines a web part’s properties – like any other file provisioned to SharePoint using the ‘Module’ element, this is not deleted when the Feature is deactivated or the Solution retracted by default. In development, this would cause a problem as updates to this file would not be reflected on the site – with the VS2010 tools, this (and many other deployment conflicts) is taken care of by Deployment Conflict Resolution during deployment:
   
   
   One cool thing is that you can set things up to prompt you rather than use the default behaviour each time – useful if you don’t want the same thing on every deployment/debugging iteration:
   
    
   Having this makes some operations much simpler – changing the name of a web part no longer requires you to find and delete the existing .webpart file in the gallery for example, it’s all handled for you. Even better, the whole process is extensible and can be built on to implement custom resolution for certain artifacts.

So all in all, the tools are a huge leap forward for SharePoint developers. Of course, something I haven’t mentioned in my list is that the dev can now take control of any file in the solution, rather than some being ‘owned’ by the tooling (as in VSeWSS for SharePoint 2007) but hopefully you knew that one already. I do feel that the ‘quick deploy’ add-on provided by CKS is pretty much a ‘mandatory’ thing if you need to work at speed, but it’s testament to the extensibility that enhancements like that can be bolted-on. Expect more such add-ons to surface (and be useful).

I’m looking forward to seeing the impact of this on the SharePoint development landscape over the next year or two.