Hello World,
This is the first in a short series of posts to follow-up from my earlier blog announcing the alpha release of SPVSX – a collection of extensions for the SharePoint development tools built into Visual Studio 2010. Whereas yesterday’s post gave an overview of the full contents of the release including work from other team members, these posts intend to provide some more detail on the bits I worked on and am passionate about, namely Quick Deploy.
Here’s what I’ll be covering:
- Background and Approach <—You are here!
- Quick Deploying a Project or Solution via Deployment Configurations and Steps (coming soon)
- Quick Deploying on demand via the context menus (coming soon)
- Auto Quick Deploy – The Real Moneymaker (coming soon)
- Other Quick Deploy features (coming soon)
- Known Limitations and Future Ideas (coming soon)
Background and Approach
Err… Quick Deploy!?
One of my primary focuses with SharePoint has always been around productive development practices. SharePoint often frustrates old-school ASP.NET developers due to the additional need to “deploy” one’s compiled code and other artefacts up into the SharePoint system, a process that can cost tens of minutes to hours over your average week. The goal behind Quick Deploy techniques is simple: to make this deployment as fast as possible for certain development (not production!) scenarios, thus supporting the usual rapid iterative build-test-fix-repeat cycle that developers go through.
A common example is when you make a change to a single line of code in an ASCX file – that file can simply be copied into the CONTROLTEMPLATES folder of the 12 hive without needing to redeploy the WSP, having the exact same result (for local development purposes). Deploying 50 such changes to this file of the course of a day may cost an hour with a full WSP upgrade (deactivate/retract/delete/add/deploy/activate), but only 10 seconds with a quick copy. [Numbers entirely fabricated for self-serving purposes!]
Another common example is around changing a single line of code in a web part – here all that needs to happen to your newly built DLL is to reinstall it into the GAC. This is never a 5 second job due to the need to recycle application pools, but it’s at least much better with a Quick Deploy when compared with a full WSP upgrade.
Quick Deploying without a 12 structure?
In the 2007 wave, most of the development community seemed to settle on either WSPBuilder or STSDEV, both for their ability to automatically build a WSP from a simple 12 hive structure, but also for their support for productive development scenarios. WSPBuilder had “Copy to 12” and “Copy to GAC”, while STSDEV (my personal choice) had flexible build configurations including “DebugQuickCopy” and “DebugRefreshAssemblyInGac”. In both cases, the Quick Copy functionality was a simple case of xcopying a folder from the solution to the old SharePoint root directory (12 hive). Developers really liked the replication of the 12 hive inside a Visual Studio project, and this also made it really easy to get Quick Deploy happening.
Earlier this year, Microsoft released a major update to their own tooling in the form of the VSeWSS 1.3 CTP, which through my previous life I had the good fortune of working on. We added Quick Deploy into the toolkit, though it was a trickier beast given the lack of “12 hive” structure in the project. The approach taken was to discover and process what would have been normally packaged in the WSP, but to then Quick Copy this instead. Further, as VSeWSS was known for processing files at package time, the Quick Deploy operations had to wait for the WSP to be built before they could reliably deploy the files from the hidden /pkg folder. Those of you who tried integrating VSeWSS with source control will hopefully have discovered that little beauty of a folder at some point, because without it, your source control wasn’t complete!
With the SharePoint 2010 tooling, Microsoft have made huge investments in providing a more intuitive way of selecting items for packaging (Package and Feature designers), as well as more straightforward grouping of SharePoint artefacts into “SharePoint Items” (SPIs). This is all great stuff, but fundamentally the same difficulty comes when thinking about Quick Deploy – there is no SharePoint Root/14 Hive folder in the solution to simply copy across, and just as in VSeWSS, files in the solution are processed before being packaged into a WSP into a /pkg folder for the purpose of substituting tokens. This all happens a lot less magically than before (there is nothing in the /pkg folder you would need to source control for example), but it still happens.
Hence in SPVSX, Quick Deploy uses a very similar philosophy and approach to that of VSeWSS, and this is the #1 thing to remember when working with it:
SPVSX Quick Deploy will only ever deploy SPIs that you have included in a feature, or a package.
Behind the scenes, this is necessary because when an item is not packaged, it is not possible to substitute tokens such as $SharePoint.Package.Name$ before quick copying them into the 14 hive. Yes, I’ve had to deal with all that stuff folks, and it was a bit of a mind boggler when considering exceptional scenarios like SPIs that are included in multiple features, some of which may be in other projects in the solution. I’m fairly confident that even in Alpha I have caught all those scenarios, and the Quick Deploy mechanism should be pretty robust.
Despite this, I believe the approach also works well from a philosophical standpoint, in that SPVSX Quick Deploy is as close to a “full” deployment as possible. If you’ve forgotten to include an item for packaging, then Quick Deploy won’t hide this from you, and failing fast is always a good thing.
When Not to Use Quick Deploy
In the hands of a noob SharePoint developer, Quick Deploy can be a dangerous thing, especially if expecations are that it will work every time. I suspect this is why it wasn’t included in the SharePoint 2010 tooling out-of-the-box, tooling which is geared towards less experienced developers (though is no less suitable now for old hats).
In any case, I would be doing a public disservice if I suggested you use Quick Deploy all the time. It’s useful for scenarios such as:
- Updating a binary into the GAC or BIN folders when you’ve already deployed the items in SharePoint that rely on that binary (such as a web part, code behind, or feature receiver)
- Updating a ghosted/uncustomised file from your solution into the SharePoint Root/14 Hive, where that change will be picked up immediately by SharePoint
- Deploying front-end enhancements that are not cached such as JavaScript and CSS.
It’s not so useful for scenarios such as:
- Updating an item in the SharePoint Root that needs further processing before SharePoint will read it, such as Feature.xml
- Updating an item where a Feature must be reactivated as part of testing
- Updating an item where more work is required inside SharePoint to complete deployment.
This is by no means a complete list, though to be honest there are not many scenarios where I don’t think Quick Deploy can be used even to get you half the way there in half the time. But the important thing is that you need to understand these edge cases and the implications of Quick Deploy, or at least accept the following rule:
If Quick Deploy fails and you’re not sure why, just revert to a full Deploy.
Closely related to this is my final disclaimer, which I hope is obvious:
Always test your code with a full Deploy before release.
Tune in next blog in the series, where I’ll provide a walkthrough on using the custom Quick Deploy configurations and steps, including some pretty pictures.
:) Matt