Controlling SharePoint 2010 Deployment in VS 2010

The default experience when you press F5 in Visual Studio 2010 is to Create, Build, Package and Deploy your solution, all at once, automagically, pretty cool. As long as you don't want to control that process. But wait, you can do that too. You can customize exactly what happens when you press F5 to meet your own needs. From copying things into specific locations, to retracting or installing solutions, to calling MS-Build to do something special, to resetting the Application Pool, to stopping and restarting services, to whatever your heart and project desires or requires. This is huge and goes far beyond pre and post-build actions we had before. You save your custom Deployment Configuration in the Project Properties panel in a new SharePoint tab.

So if you want to Quick Deploy a web part into the application \bin or GAC, or update your application page without having to recycle the App Pool, you can write a Deployment Configuration just for any of these scenarios. You can build Deployment Configurations to copy specific files for particular environments (DEV/ACC/PRD), do your packaging and FTP the files out for code review without adding a Deployment step. Truly cool. You get two for free - Default deployment (the aforementioned Create, Build, Package and Deploy), and No Activation which does pretty much what the name implies.

You can take this a step further by creating custom actions to reuse in any Deployment Configuration, perhaps to execute SharePoint commands. Since VS is 32-bit and SharePoint is 64-bit, for this you'll use a new thing called a SharePointCommand that marshals your code into a 64-bit thread and executes it on your behalf. It actually binds to a thread identical to the one that serves the URL that your project is affiliated with. There's some cool stuff going on here - you don't need to attach the debugger to the worker process anymore (w3wp.exe ), that wire-up happens for you. And the same goes for code you marshal into that context using a SharePointCommand - any VS extensions you care to write can execute code in the SharePoint context associated with your project. Ted Pattison's seasion also went deep on the next steps - packaging the new component (in this case a Deployment Configuration option) into a VSIX file for passing on to anyone else who wants to use your option in their IDE.

More great nuggets

• No more DDF files! The Package Builder takes care of all the gory details.
• Automatic generation of Features, Manifests, .webpart files and supporting files.
• While the Feature manifest generates all you need, you can provide your own nodes to merge into the generated manifest, or override the process completely (but like, why)

 All in all, there'ssome pretty awesome control to be had over the deployment process.

* Notes based on a presentation by Eric Shupps at SharePoint Conference 2009 (#SPC09)