A run-down of new features in Web Deploy 2.0

Posted: Feb 03, 2011  1 comments  

Average Rating

Share this Post

Web Deploy 2.0 has been out for a few weeks now. If you don’t have it, I encourage you to go get it now. I’ve been meaning to do a blog post on what’s new … so here it is:

 

1) Continuous publishing. If you use WebMatrix, you are already using this feature. Web Deploy 2.0 has the ability to create a store of web app-specific settings in the IIS web server’s configuration directory. These settings can be used when a web app is synced to a destination.

Let’s take a concrete example: suppose you have installed DotNetNuke from the Web Application Gallery in WebMatrix. Application Gallery packages are just Web Deploy packages with manifest.xml and parameters.xml files. During the initial install, WebMatrix uses Web Deploy 2.0’s continuous publishing feature to store the application’s original manifest and parameters (highlighted below) along with user-supplied values for parameters for each computer the application is published to. In the screen below, the application has been installed or ‘published’ to localhost, so you see a folder for that computer.

The net effect is that not only can the application be published to another computer once it has been installed on your computer, it can also be downloaded from a remote computer. Hence the ability to ‘continuously’ publish an app again and again without losing any of its parameters or manifest entries.

Of course, the store is programmatically accessible via public APIs. I am planning on showing some sample code for it in a couple of weeks – if you’re really interested in it, drop me a line at baslam at microsoft dot com, and I might share it sooner. The store is currently enabled only on IIS Express.

image

2) Side-by-side setup. It is now possible to have different versions of Web Deploy live side-by-side. Web Deploy 2.0 is backwards-compatible with Web Deploy 1.1 at an API level. We hope this lets our customers try out new versions of Web Deploy without breaking existing systems.

image

3) Ability to sync a GAC assembly to destination without having it installed on the source.

One common customer request has been to be able to install a GAC assembly on the destination without having it installed on the source. This is typically required in build machines, where you don’t want to add extra DLLs to the GAC. Web Deploy 2.0 has a new provider which uses the same APIs as gacutil.exe to install signed assemblies into the GAC:

msdeploy.exe -verb:sync -source:gacInstall="c:\mybuild\myassembly.dll" -dest:auto,computername=”remotecomputer”,username=foouser,password=somepassword, authType=basic –allowUntrusted

This will install myassembly.dll into the remotecomputer’s GAC.

3) Improved database providers

Web Deploy1.1 already contained the ability to sync SQL databases using the dbFullSql provider, and MySQL databases. We have now added the ability to sync Sqlite databases as well via the dbSqlite provider. You do need Sqlite installed in the same path as msdeploy.exe:

msdeploy.exe -verb:dump -source:dbSqlite="Data Source=filename;Version=3;Password=password;"

dbFullSql also supports syncing SQL Compact databases to SQL Compact and to SQL Server.

 

Questions? Comments? Feel free to drop me a line at baslam at microsoft dot com

Comments

The new GAC sync functionality is great.  It would have been even better if the gacInstall and gacAssembly providers in this new release could support assemblies targeting the 4.0 framework.

Feb 18 2011 by AgustinM

Submit a Comment

  • Plain text is accepted.
  • URLs starting with http:// are converted to links.