• <1 minute

Web Deploy 3.6 Beta Released

We're happy to announce that Web Deploy 3.6 Beta is now available for download. This release adds new enhancements for: Support for publishing ASP.Net vNext web applications Command line and API…

We’re happy to announce that Web Deploy 3.6 Beta is now available for download. This release adds new enhancements for:

  • Support for publishing ASP.Net vNext web applications
  • Command line and API support for consuming publish setting files
  • Proxy support

Additionally, there are a number of bug fixes including ones for:

  • Checksum + Parameterization issues for remote sync’s
  • Session affinity cookie parsing issues

 

Support for publishing ASP.Net vNext web applications

We added a new contentLibPath provider, which allows you to perform incremental publishing for ASP.Net vNext packages and source files. The folder structure for vNext apps has been changed to place your application code under a new folder called “approot”, which will always be a sibling to the base of your IIS application. For example, if the base of my IIS app is called “wwwroot”, there will now exist a folder parallel to it called “approot.”

  • c:siteNamewwwroot
  • c:siteNameapproot

At the moment, the provider takes in a path to the base IIS application folder (just like contentPath and iisApp), though this usage may be subject to change. Here is an example:

  • msdeploy.exe -verb:sync -source:contentPathLib=c:siteNamewwwroot -dest:contentPathLib=siteName

If you don’t want to explicitly call this provider, you can also pull it in with the iisApp or contentPath providers by specifying a new link extension:

  • msdeploy.exe -verb:sync -source:contentpath=c:siteNamewwwroot -dest:contentpath=siteName -enablelink:contentlibextension
  • msdeploy.exe -verb:sync -source:iisApp=siteName -dest:contentpath=siteName -enablelink:contentlibextension

If you’re hosting Web Deploy, we realize that allowing users to publish to a new folder outside of wwwroot may be scary, so we decided not to add a delegation rule for this provider by default. So for now, you’ll need to make sure the contentPathLib provider is added to your rules before users can publish to your system.

 

Command line and API support for consuming publish setting files

We realize that the command line is not pretty. So in an effort to make it just a little simpler, you can now specify a publish settings file on the command line. What used to be this:

  • msdeploy.exe -verb:sync -source:contentPath=c:siteNamewwwroot -dest:contentPath=siteName,computername=https://siteName/msdeploy.axd?site=siteName,username=myUser,password=myPass,authtype=basic

Can now be simplified to this:

  • msdeploy.exe -verb:sync -source:contentPath=c:siteNamewwwroot -dest:contentPath=siteName,publishsettings=c:siteName.PublishSettings

Likewise, the previous API usage can be simplified from this:


DeploymentBaseOptions destBaseOptions = new DeploymentBaseOptions();
destBaseOptions.ComputerName = "https://siteName/msdeploy.axd?site=siteName";
destBaseOptions.UserName = "myUser";
destBaseOptions.Password = "myPass";
destBaseOptions.AuthenticationType = "basic";

To this:


PublishSettings destSettings = new PublishSettings(@"c:siteName.publishsettings");
DeploymentBaseOptions destBaseOptions = new DeploymentBaseOptions(destSettings);

 

Proxy Support

We finally have proxy support for Web Deploy… mostly. 🙂 If you’re still publishing to port 8172, then by default we will still ignore any proxy settings that you have. This was to prevent breaking existing customers who use proxies that don’t allow port 8172 through. If you still need proxy support for port 8172, then you can override this with a registry key by setting:

  • HKEY_LOCAL_MACHINESOFTWAREMicrosoftIIS ExtensionsMSDeploy3AlwaysUseProxySettings = 1