Core components of Microsoft Web Deployment tool

There are four concepts that are important for you to understand to be able to effectively use the new Microsoft Web Deployment Tool.

 

1. Providers

Providers are pieces of code that provide data to the tool for various operations like sync.  The tool always starts with one provider, with an optional path for the provider. The provider builds the view of the part of the system it can handle, and uses other providers to represent system parts that they handle. These views are internally represented in xml. For example, if you begin with the dirPath provider, it will build an xml view of the folder (specified by the path), which will include files and subfolders present in it. It will delegate the task of handling files to the filePath provider and handling subdirectories to another dirPath provider object.

Parameters you pass in the –source and –dest switches at the command line specify the providers which builds xml views of source and destination systems. Then, the tool only needs to compare these xml views and call for Add, Update, or Delete operations on the destination to make its xml view same as source. Each provider is responsible for handling each of these operations.

Some examples of providers that are provided out of the box are dirPath, appHostConfig, and metaKey. You can see the full list of supported providers in Microsoft.Web.Deployment.config or by running the tool with no parameters to see the Help output. The tool also supports custom providers, which are built by combining one or more existing providers. Two examples of built-in custom providers are the webServer and webServer60 providers, whose definitions can be found in Microsoft.Web.Deployment.config. You can also create these custom manifests in a separate xml file and then use –source:manifest=<xmlfile> to use it as a source. When doing a sync or migrate, the same provider must be used for the source and destination. So if you are using a manifest as the source of your operation, you must also use the manifest provider as the destination. The only exception is the archiveDir provider, which can be used with other providers.

2. Links

Link extensions (or links) are executed for each entry generated by the providers. Links basically connect otherwise unrelated data based on logic coded in the extensions. An example of a link extension is the ContentExtension, which pulls in content whenever it sees a virtualDirectory configuration element added by appHostConfig provider or sees a path metaProperty. It does this by adding a dirPath entry under the virtual directory configuration, and the dirPath provider then pulls in all the content. Another example is the CertificateExtension, which is responsible for pulling in certificate whenever SSLCertHash is seen in the configuration.

Link extensions are executed for all verbs, so a dump will also cause link extensions pull in additional data. If you want to disable a link extension while executing a command, you can use –disableLink switch provided. For example, –disableLink:ContentExtension will cause content to not be included in a view of virtual directory configuration, which would allow for syncing of two servers without moving any content. Link extensions rely on providers to actually pull in the data and are limited by what providers are supported and can do. Together providers and link extensions provide the view of the system that can be dumped, archived, synced, or migrated.

3. Rules

Rules are small pieces of code that have logic to do something special and are evaluated only when a sync operation is performed (not during a dump). A few examples of things that rules do are normalizing paths using environment variables, skipping UNC paths, skipping configProtectedData configuration, etc. By default, rules only run if they are marked with the isDefault attribute set to true. The -enableRule and -disableRule switches will enable or disable a rule explicitly at the command line. For example, –disableRule:SkipUNC will cause UNC content to be included when doing a sync or migrate, because it is disabling the default rule to skip all UNC content. The list of rules can be seen in Microsoft.Web.Deployment.config.

It is also possible to create custom rules that are variations of existing rules. For example, a rule to skip all content located on drive G: would be of the same type as the SkipUNC rule in the configuration (Microsoft.Web.Deployment.SkipRuleHandler). But the absolutePath attribute would be set to “G:\\.*” instead of “\\\\.*” in the configuration file. –skip and –replace switches provided by msdeploy.exe enables creation of new rules as a command-line parameter at runtime, that are included while doing a sync or migrate operation.

4. Methods and Verbs

Methods and verbs are the operations allowed by the tool, which are called using the –verb switch at the command line. If the verb specified is not dump or sync, it is expected to be a method that is specified in the configuration. Currently, the supported methods are GetSystemInfo and GetDependencies.

 

Hope this helps. 


Kanwal, Nina, Faith

3 Comments

  • Does this employ the Microsoft Sync Framework? Sure sounds like there is some overlap there, right?

  • Davidacoder,

    No, this tool doesn't employ microsoft sync framework. Microsoft sync framework solves multimaster sync problem which is much more complicated. Microsoft web deployment tool is a single master sync solution and lot of objects we deal with are web server specific. For this reason Microsoft sync framework team recommended us to build a standalone solution.

    Thanks.
    Kanwal

  • Object reference not set to an instance of an object.

    How do I solve this?

Comments have been disabled for this content.