This blog post is part of a series of posts on the web deploy providers.
This is what MSDN says about the contentPath provider:
The contentPath provider synchronizes Web site content.
The contentPath provider is basically a “web version” of the dirPath provider, hence you can use it when you’re working with web site content.
Unlike the filePath and dirPath providers that operate on either files or directories, the contentPath provider can work with files, directories and web site content:
- A directory path (e.g., “C:\inetpub\wwwroot\www.example.com”)
- A file path (e.g., “C:\inetpub\wwwroot\www.example.com\index.html”)
- A site path (e.g., prod.example.com)
- An application path (e.g., prod.example.com/images or prod.example.com/js/jquery.js)
The contentPath provider actually uses the dirPath and filePath providers to implement its functionality which makes it a better choice in many situations.
As with the dirPath and filePath providers the following still applies:
- UNC paths and mapped network drives are supported.
- Environment variables like %windir% are supported, but wildcard characters are not.
- If the path contains spaces, the path must be enclosed in double quotation marks.
The contentPath provider takes an argument that’s one of the following:
- a directory path
- or an UNC path
- a file path
- a site path
- an application path
Special Settings or Considerations
Because the contentPath provider is basically a “upgraded” version of the dirPath+filePath providers the following still applies:
- Files on the destination that do not exist on the source will be deleted by default.
- By default, the provider doesn’t synchronize ACLs, attributes, or ownership information. This is because the permissions are copied as security identifiers (SIDs) and may not work uniformly on all computers.
If you need to synchronize both permissions and content, you can use the optional includeAcls provider setting to include ACLs in the sync operation.
note: ACLs will be copied as SIDs. For the permissions to be set correctly, you must use domain accounts or have local accounts with matching SIDs on both the source and destination computers.
For IIS 7, the contentPath provider relies on the ability of the caller to read the ApplicationHost.config file whenever you specify an application path. Impersonation of a user account that has access to read properties in the ApplicationHost.config file is required.
note: an example of this situation can be seen here.
All of the examples I demoed on the dirPath provider will apply just as well (or better) with the contentPath provider as well so I’ll show you some that will apply better (or just with) with the contentPath provider.
I’m using the same setup as I did with the dirPath provider which is shown below.
All the examples presume that we have a build server in our company domain.
The hosting environment for our production site (http://www.example.com) resides in the hosting provider’s domain which our build server has no knowledge about.
We’ll use a command-line to execute the web deploy commands.
note: more on remote execution of web deploy command and how to configure for such an environment can be read here and here.
First let’s simply try to “read” (dump in web deploy terms) the content of IIS site prod.example.com from one of the remote web servers (WFE1)
In a dump operation it’s only required to supply the source argument in which I’m using the contentPath provider as you can see on line 3.
Error: Object of type ‘contentPath’ and path ‘www.example.com’ cannot be created.
Error: An error occurred when reading the IIS Configuration File ‘MACHINE/REDIRECTION’. The identity performing the operation was ‘xxx’.
Error: Filename: \\?\C:\WINDOWS\system32\inetsrv\config\redirection.config
Error: Cannot read configuration file due to insufficient permissions
Since I’m executing the command against a remote server where I don’t have the correct permissions to read ApplicationHost.config I get the error shown above.
I have to either:
- run the command-line as a user that has the correct access to server WFE1
- add required information to the command to be able to execute the remote command
I’ll use option 2 since my build server is not a member of the remote domain and I can’t run the command-line as a user of the remote domain (read more).
Now, that gist shows a command that will work since I’m providing information necessary to read ApplicationHost.config on WFE1.
2. Synchronize using a site path between servers
A pretty common scenario for the contentPath provider is to use it to synchronize web application content between servers.
Let’s assume this little deployment workflow (might not be to uncommon):
- The build server has compiled, tested, and packaged (via package provider) a new version of our web site.
- The build server has “pushed” (sync in web deploy terms) the new version up to server A (WFE1) which we could see as the primary server in our little “web farm”.
- The build server synchronizes the content or the web site to the other servers in the web farm (in our case that will be WFE2)
Steps 1 and 2 have already been accomplished and we’ll focus on solving step 3 which is this if you remember:
What we want to accomplish is:
- Trigger the sync operation with WFE1 as source and WFE2 as destination.
- The command will be executed from an outside/off-site server.
- We only want to move content and not configuration.
On line 3 I’m ‘connecting’ to the source using the contentPath and a a site path argument.
On line 7 I’m actually using another provider, the auto provider, since the web application on the destination has the exact same name. That saves me some effort since the providers are the same on both source and destination.
Lines 4-6, 8-10 (and 11) are need for me to ‘establish a remoteconnection’ to servers VIRJOLE-WFE1 and VIRJOLE-WFE2.
note: I’m using ‘stored credentials’ which you can read more about here.
2.1 Why not use the appHostConfig provider?
There’s of course other providers I could have used to sync a web application between two servers. One of them being the appHostConfig provider.
Here’s why I’m not using it in this example though.
Now when we execute the web deploy command using the appHostConfig provider instead this is what happens:
Since server A (WFE1) didn’t have the ‘extra’ binding it was deleted from server B (WFE2) when I synced. That’s why contentPath is better (only content).
3. Synchronize using an application path between servers
As a last example I’m just showing you how to sync using an application path argument (if you would like to “limit” the contentPath a little bit).
Sometimes it might be useful just to sync a specific part of an application, I’m using the /Views folder to exemplify that.
This might be useful in a situation where you don’t want to sync content that can cause the application to restart (/bin, web.config etc.)