Default physical path when deploying web applications using MSDeploy

MSDeploy will use the physical location of the web site that the web application is being deployed under, if you're deploying a web application without specifying a physical location in the parameter settings.

Specifically, MSDeploy uses the physicalpath attribute for the site defined in the applicationHost.config file, which is located C:\Windows\System32\inetsrv\config.

So for example, my default web site is defined as physicalPath="E:\inetpub\wwwroot", which is specified in the virtualDirectory element. I have an application whose virtual path is under the default web site. When I deploy this application, which doesn't have a physical location specified as a parameter, it will use E:\inetpub\wwwroot as the base, and create a sub folder - e.g. E:\inetpub\wwwroot\NewApplication.

One thing to keep in mind, once the deployment has been performed, a new application element is created in the applicationHost.config file for the web application deployed. If you delete the application from IIS - the configuration remains for the application. This is key to remember, as this will now become the default physical location for the application, regardless of the physical location of the default web site. So if you want MSDeploy to use the default web site's physical address as the base address (assuming your deploying your applicaion under DWS), then you'll have to manually delete the application element for the web application in the applicationhost.config file before executing the deployment.

Creating MSI installation scripts using Orca

ADDLOCAL is an argument you can pass to a MSI installation package when invoking through the command line. It allows you to specify which features you want to install that are available as part of the MSI. Which is great, however how do you know what the features are called?

Orca is the answer. Orca is available in the Windows SDK, although it’s an additional install once you’ve installed the SDK.

Open the MSI using Orca, where you’ll be present with a lot of meta data about the MSI. The table we’re interested in is Feature. Listed are all the feature names which can be passed in the ADDLOCAL argument.

So for example, I wanted to make sure the MSDeploy Service Agent feature is installed (it’s not installed by default so if you install the MSI using quiet mode / no UI, it’s not included). Using Orca I was able to figure out what the name of the Agent Service feature is called according to the MSI (which was MSDeployAgentFeature)

So my powershell script to install MSDeploy looked something like: start-process -filepath msiexec -argumentlist /q, "/l log.txt", "/package webdeploy_x64_en-us.msi", "ADDLOCAL=""MSDeployAgentFeature,MSDeployUIFeature""" –wait ...where I’ve indicated I want the UI and Agent features installed. Without Orca I would have no idea what they are called. Orca can also indicate what public properties are available when invoking the MSI, which is the Property table.

appHostSchema provider ignoring files when synching

I was packaging the schema config files for IIS using the appHostSchema provider which included my custom file. When the package was created, my custom file wasn't included. This was also occuring when I was synching server to server, rather than using a package to see if that would make a difference. Again, my custom file was being excluded from the synch. This was working fine a couple of weeks ago.

Eventually I found out why this was occuring, I had recently put my custom file in source control which meant the file had become read-only. I manually copied the file to the config\schema folder on my local pc. When I tried to packing the files on my pc, it was now being excluded.

Once I turned off the read only setting, my file was once again included when synching.

MSDeploy with Declare and Set parameter files

One of the most undocumented parts of MSDeploy is the declare and set parameter xml files you can use to encapsulate the parameters declaration and setting rather than having them clogging up the command line call to MSDeploy.

So firstly, here is how to include them when packaging and deploying:

msdeploy.exe" -verb:sync -source:apphostconfig="default web site/application” -dest:archivedir="C:\packages\application" -declareParamFile="C:\source\application\deployment\declareParamsFile.xml"

msdeploy.exe" -verb:sync -dest:apphostconfig="default web site/application” -source:archivedir="C:\packages\application" -setParamFile="C:\source\application\deployment\setParamsFile.xml"

You can verify that the parameters were correctly generated when the package was generated by examining the parameters file in the package folder.

The format of the declareParamFile is exactly the same as the parameter file that is generated in the package when you specify them manually in the command line – e.g. below is the content of the declareParamsFile.xml file.

<parameters>
<parameter name="enabledProtocols" defaultValue="http,net.pipe">
<parameterEntry kind="DeploymentObjectAttribute" scope="application" match="application/@enabledProtocols" />
</parameter>
<parameter name="applicationPool" defaultValue="synctest">
<parameterEntry kind="DeploymentObjectAttribute" scope="application" match="application/@applicationPool" />
</parameter>
<parameter name="providerServiceAddress" >
<parameterEntry kind="XmlFile" scope="web.config" match="//configuration/system.serviceModel/client/endpoint[@name='NetNamedPipeBinding_ProviderCustomerDetails']/@address" />
</parameter>
<parameter name="physicalPathLocation" description="Physical path where files for this Web application will be deployed." defaultValue="E:\Install\Services\ExampleService\" tags="PhysicalPath">
<parameterEntry kind="DestinationVirtualDirectory" scope="Default\ Web\ Site/iag\.application\.services\.exampleservice/" match="" />
</parameter>

Parameters are defined using various kind types. The common type is DeploymentObjectAttribute which allows you to configure the values within the archive.xml file using an XPath expression to determine where the update should be made. The archive.xml file is generated when the package is created and defines configuration for the deployment – e.g. if a website was packaged using the AppHostConfig provider, then it will contain the setting for which AppPool to use when the site is deployed. Create a deployment package, then open the archive.xml to better understand what this means. For a list of parameter kinds available see here http://64.4.11.252/en-us/library/dd569084(WS.10).aspx.

Once the deployment package is created, the parameter file generated within the package will contain the parameters specified in the declareParamFile.

Below is an example of the setParamfile and the format that should be used. Note that the name of the setParameter elements is the same name as their corresponding declaration in the declareParamFile example above.

<parameters>
<setParameter name="enabledProtocols" value="http, net.pipe"/>
<setParameter name="applicationPool" value="ServiceNameAppPool"/>
<setParameter name="providerServiceAddress" value="net.pipe://server/servicename/endpoint.svc"/>
<setParameter name="physicalPathLocation" value="C:\Services\ServiceName\"/>
</parameters>

When performing the deployment to the destination web server, to include the setParamFile file use the –setParamFile switch in the command line – e.g. setParamFile="C:\source\application\deployment\setParamsFile.xml"

Probably my favourite parameter kind is XmlFile (providerServiceAddress) which allows you to specify a xml file (which would typically be the web.config when deploying web applications) to be updated when the deployment is executed. You specifiy a XPath expression to indicate where you want to update the file. This is great when moving through different environments as the web.config usually contains environment specific settings.

MSDeploy, MSBuild and environment specific config files

MSBuild's property switch (/p:) allows you to override project-level properties. Using /p, you can specify which configuration you wish to build against - therefore if you have your environment specific config files transforming correctly (more details here http://blogs.msdn.com/b/webdevtools/archive/2009/05/04/web-deployment-web-config-transformation.aspx) – you can automate building environment specific deployment packages using MSBuild by using the target switch (/t:) and specifying Package - which results in MSDeploy being the deployment mechanism used.

So an example of this: MSBuild "[project name].csproj" /T:Package /P:Configuration=[environment configuration name i.e. Staging];PackageLocation="[zip file name & path]"

So the model would be - create a config file per (configuration) environment, and create a deployment package per (configuration) environment using the above command line. Therefore you have a deployment package per environment ready to go without have to make any environment specific changes to the config files. Nice and clean, plus with the added bonus that the package generated contains a deploy.cmd file which encapsulates MSDeploy to roll out the package.

More useful info on MSBuild and packaging: http://vishaljoshi.blogspot.com/2009/02/web-packaging-creating-web-packages.html

MSDeploy bug with config providers

Discovered a small but annoying bug when synching config files where the destination config file doesn't have the configSections element declared (which is common when synching the root web.config file), and the source config file does have this section (so in other words the configSections element will be added along with the new section/sectionGroup definition)

So assuming you have the required synching rules turned off (SchemaSection rule, or editing the MSDeploy config settings file), after the synching occurs, the new configSections element is created by MSDeploy... however, it's not placed at the top of the config as the first child element of the root configuration element.

If the configSections element is in a configuration file, the configSections element must be the first child element of the configuration element.

So the work around, is to manually add the configSections to the destination config file before performing the sync. Doing so means that new section/sectionGroup is added in the correct place in the config file.

MSDeploy 1.1 does not sync 4.0 assemblies

Doesn't seem to be a lot on info on this, hence I spent a while trying to sync some .Net 4.0 assemblies using MSDeploy - however, received confirmation today from the IIS team that version 1.1 of MSDeploy can't do this. Obviously this is on the feature roadmap since you can sync the 4.0 machine and web config files.

http://forums.iis.net/p/1168877/1949692.aspx