SharePoint Deployment Packaging

Two different deployment configurations, Default (Activates), No Activation.

Fully customizable along the entire chain of the deployment.

A configuration is a set of steps and the action for each step, there are also pre and post deployment commands can be attached to any configuration. You can only have on active deployment per configuration per project, cannot be chained.

There is built-in conflict resolution

  • Automatic
  • Prompted
  • None

Customizable through the SharePoint Project Item Extensions

Basically it's a rollback like an MSI that fails.

Demo of the basic steps, showing a graphic of how all the pieces of the Deployment fit together.

Feature explorer shows you a nice window that allows you to add/remove and change the properties of a feature, and set other properties. You can also set dependencies for the feature here. You can still edit the raw XML, with a nice dual pane window that allows you to merge with the auto-generated xml.

Will not work at all with 2007, because it will only work with a 2010 template.

Package explorer is similar to the feature explorer, except of course it deals with a package. There is an advanced tab that you can add extra assemblies to the package.

Someone asked if you can import your existing WSP's into VS2010, Mike Morton (lead for the Visual Studio team) said 'Possibly', which of course made everyone laugh. He's really not sure if it's possible.

Great question about how do you deploy to production? Need to create your own deployment scripts, just need to replace the steps in dev. For production they FTP WSP's to a folder in production, then a service monitors the location and then performs the steps needed to retract and deploy correctly.

There is a SharePoint command context that lets us to run 64-bit commands from Visual Studio without any issues. WHEN are they going to upgrade Visual Studio to 64-bit??????

Creating a deployment command/step

There are three parts to a deployment command, the actual commands, adding the steps, then adding the steps to the configuration, and all this must be in a VSIXProject.

There is a quirk, you must set the output directory of your package to be the directory of the VSIXProject directory.

You can create and manage a configuration all from code as well.

When creating a VSIX project, the framework must be 4.0, the same with the SharePoint commands project.

Well, first time I've seen it, but he was able to crash the Visual Studio 2010 Beta 2