Announcing Web Deploy 3.0 Release Candidate!

We are happy to announce that we have just released the Release Candidate for Web Deploy 3.0. You can download the x86 or x64 versions.

If you are new to Web Deploy, Please read our Introduction to Web Deploy tutorial. Currently Web Deploy RC is only available through direct download. We are still working on WebPI feed. Easiest way to install V3 RC is to first install Web Deploy V3 Beta using WebPI 4 beta (x86/x64) as instructed in Installing & Configuring Web Deploy tutorial, and later update it using RC setup.  Web Deploy 3.0 beta will be upgrade to the RC version, and this V3 will continue to live side-by-side with Web Deploy 2.0 & Web Deploy 1.1.

Here's a rundown of new features:

1. Publishing & Migration to IIS8

You must have heard about our latest & greatest server release Windows Server 8 Beta. It comes with IIS8 which has lots of cool new features. To take advantage of these features, you might be thinking about migration strategy from your existing IIS Servers. Web Deploy 3.0 fully supports migrating to IIS8 from IIS 6, IIS7 and IIS7.5.  Please follow our documentation walkthrough on migration

  1. Synchronize IIS
  2. Migrate a Web Site from IIS6.0 to IIS7 and above

Publishing experience for IIS8 is no different than publishing to IIS7, you can learn more about publishing in our tutorial "Testing Web Deploy Publishing From Visual Studio 2010 and WebMatrix." 

Note that WebMatrix 2.0 and Visual Studio 11 are still in beta and they shipped with beta version of Web Deploy 3.0. Web Deploy team has not done extensive testing of compatibility between beta versions of these products with RC version of Web Deploy 3.0, so we would recommend you to wait for WebMatrix and Visual Studio teams to release post beta builds if you are planning to do anything more than just testing out new features of Web Deploy 3.0 in test environments.

2. Automatic Backup       

One of the common feedback we received that customers often make mistakes while publishing changes to websites. This is especially true for amateur developers and small business owners. It is very hard to recover from these mistakes. In Web Deploy V3 RC we are introducing new feature "Automatic Backup" which will allow server administrators to configure servers in such a way that each publish will automatically generate a backup and store it on server. If you need to roll back or go to a previous version, you will be able to do it without involving server administrator.

You can learn more about this feature in our "Automatic Backups" Tutorial.  Please do provide your feedback on this brand new feature!

3. PowerShell Cmdlets

Web Deploy command line is very versatile which also makes it equally complex. Based on your feedback, team has invested into PowerShell Cmdlets for common Web Deploy tasks. We are releasing more than 20 PowerShell Cmdlets in this release for very first time.

Powershell cmdlets includes help description as part of cmdlets themselves. More details are provided in "PowerShell Cmdlets" tutorial.

4. Improved parameterization

Web Deploy supports parameterization of publish settings during deployment time. To learn more read Web Deploy parameterization.

Earlier versions of Web Deploy only supported replacing attribute values which already existed as part of the package. We have added support for

  1. Extend the current xml parameterization beyond attribute value replacements to a more complete xml modification story by allowing addition/deletion/replacement of new elements.
  2. Accept the replacement data for parameters to come from the server, from the package itself or from the source.

Here is one example of a parameters.xml file which will add newNode to all nodes including the root in target xml file.

<parameters>

  <parameter name="Additive" description="Add a node"   defaultValue="&lt;newNode />"  tags="">

    <parameterEntry kind="XmlFile" scope=".*" match="//*" />

  </parameter>

</parameters>

Below are some examples which demonstrate how to get the values from other places

Get values from remote server:

<parameter name="Replacement Param" defaultValue="\\myshare\share\web.config:://connectionStrings" >”

  <parameterEntry kind="XMLFILE" scope="web\.config$" match="//connectionStrings" />

</parameter>

Get values from a file in the package that is being synced:

<parameter name="Replacement Param" defaultValue="\web.config:://connectionStrings" >”

  <parameterEntry kind="XMLFILE" scope="web\.config$" match="//connectionStrings" />

</parameter>

More details about parameters.xml file can be found here

5. ApphostAuthOverride Provider

This is a new Web Deploy provider which will provide support for changing authentication mode for a given website. Many a times in enterprise environments applications want to choose their own authentication method using web.config file, but AppHostConfig file locks this setting.  This means that if a developer tries to set his/her site's authentication settings, IIS will not obey it.  The Application Host Authentication Override provider allows developers to configure how IIS locks an authentication setting on the server by adding a <location> tag for that setting within the server's applicationHost.config file.  Here is an example of what that looks like in config:

   <location path="siteName" overrideMode="Allow">

        <system.webServer>

            <security>

                <authentication>

                    <windowsAuthentication />

                </authentication>

            </security>

        </system.webServer>

    </location>

 Here is a few command line examples of how this could be done (msdeploy.exe is located under "%programfiles%\IIS\Microsoft Web Deploy V3"):

·         Allow Windows Authentication on Destination at site = SiteName: 
msdeploy.exe -source:ApphostAuthOverride -dest:ApphostauthOverride="<siteName>;windowsAuthentication=Allow"

·         Allow ASP.Net Forms Authentication on Destination at site = SiteName:
msdeploy.exe -source:ApphostAuthOverride -dest:ApphostauthOverride="<siteName>;aspNetAuthentication=Allow"

·         Deny Anonymous Authentication on Destination at site = SiteName:

msdeploy.exe -source:ApphostAuthOverride -dest:ApphostauthOverride="<siteName>;anonymousAuthentication=Deny"

·         Reset Windows Authentication Setting on Destination at site = SiteName:
msdeploy.exe -dest:ApphostAuthOverride="<siteName>;windowsAuthentication"

Please note the sytax carefully, both <sitename" and authentication setting are part of -dest:ApphostAuthOverride value.

6. Others

Apart from these new features there are many bug fixes in the release. Please follow ReadMe file for more details.

3 Comments

  • There was a related question on the forum about deleting an existing parameter
    http://forums.iis.net/t/1189770.aspx


    "In the release notes for the 3.0 release of web deployment it mentions that it should now be possible to delete parameters as part of the deployment process. However I cannot find any examples of this or any details on how to do it.

    Is anyone using this functionality or know where I can locate the documentation."

    Here is the posted answer

    "If you had a web.config that looked like:








    and you want to delete the node directoryBrowse you couldadd a parameter to the parameters file that looked like:







    And then to remove the node you would set the value of the parameter to be "". So if you are using a set parmeters file it would contain something like:



    To summarize, the match needs to be the path to the node you want to remove and you need to set a parameterValidation kind of allowEmpty. Then set the value of the parameter to empty to replace it with nothing."


  • Sorry..wasn't logged in. My question is about using MSBuild Arguments in a TFS auto-deploy scenario. BASIC auth was the default and only option in V2 of WebDeploy (WMSVC) I'd like to use NTLM without putting the password in the build script. Is this now possible? Can I just add the tfs user to the delegate permissions in IIS or maybe as an admin and have the deploy work? We need to avoid putting passwords in build scripts. This is never going to be allowed in our stage or production environments...

  • Please folks, PLEASE!! I'm BEGGING you!! Add a rollback feature or some disaster recovery to this wonderful tool!! I LOVE Web Deploy, but I always have to publish to a separate directory, then remap my virtual directory to that so I can rollback if needed. Sometimes you get a bad deploy you know?

    Seriously, I BEG you to add this feature soon. Make it a Web Deploy 3.1 release or something. It shouldn't be that hard really. The concept is really quite simple you know? I would have no need for any other tool if you could do this, ideally implemented with site versioning and auto remapping in IIS to the new directory and optionally zipping (archiving) the old one.

    Excellent work Scott Gu and team!! :)

Comments have been disabled for this content.