In VS 10 we use MSDeploy behind the scenes to deploy your entire web application along with all of its dependencies like IIS Settings, DB, web content etc to any destination server.

MSDeploy is a new technology specially designed to serve the purpose of deploying web applications seamlessly across IIS Servers. My hope is to give you a CONCEPTUAL high level overview to understand how web deployment with VS10 & MSDeploy really works.

In case of web deployment or replication across server farms what you really require is to take the web and its dependencies from one box to another. To further over simplify there is a source (your dev box) and there is a destination (your web server), the source needs to be replicated on to the destination and that is what we are trying to achieve (with of course a lot more details behind the scene :-)

MSDeploy uses this simple concept of taking the source and applying it on to the destination. Let us try to understand what all are possible sources:

Source:

- If you want to deploy the site you are developing on your dev box then now the site you are developing on the dev box becomes the source.
- If you have your web content stored in the source control and you have a build server which is set up for automatic deployment then the build server becomes the source.
- If you have a MSDeploy web package given to you by someone and you are trying to install it on your dev box then the web package becomes the source.

Destination:

- If you are deploying a web to a test server then the test server is the destination.
- If you are creating a web package out of your web site using MSDeploy then the web package becomes the destination.
- If you are deploying to your own dev box for testing purposes then in this case your dev box itself becomes the destination.

Well the concepts of source and destination are pretty simple but the reason why they are so interesting is because when you set up your deployment settings in Visual Studio then VS creates something that we call as Source Manifest and feeds to MSDeploy. Check out the figure below which gives you an idea of how VS 10 will produce your web package:



Source Manifest is a simple XML which instructs MSDeploy on what all Providers to invoke on the source machine. So what is a MSDeploy Provider?

A MSDeploy provider is a simple object which MSDeploy engine invokes to do two major CONCEPTUAL tasks:

1. On Source Machine to GET the right content from its place

e.g. if you had Database attached to your web then at source DB Provider will be called to pull out your data and schema and convert it into SQL Scripts which will then go into the web package.

2. On Destination Machine to PUT the right content in its place

e.g. if there were SQL scripts in your web package then at destination DB Provider will be called to run the SQL command and the SQL scripts to create and set up the database

MSDeploy comes with a lot of pre-built providers like:

- IIS Settings providers for IIS 5.1 (for XP), IIS 6.0 (for Win2K3) & IIS 7.0(for Vista & Win2K8)
- DB Provider for MS SQL Server
- GAC
- COM
- Registry
- etc etc

Based on your project settings Visual Studio creates a source manifest which is fed to MSDeploy to create package or deploy your web application. So on the source box below is how MSDeploy works:



Along with creating the source manifest, Visual Studio also creates destination manifest for you. Check the below diagram:



When you are ready to deploy then on the destination you can feed the web package and the destination manifest to MSDeploy to deploy your web site. In the destination manifest you can change the values like “IIS Application Name”, “DB connection strings” etc.



This is how you can use web packages on any machine with MSDeploy and by configuring your deployment options in the destination manifest you can go and and easily recreate your webs.

It is not possible for someone to come up with every possible provider that everyone needs so there will be an extensibility model by which you can write your own providers and register it with MSDeploy engine.

Visual Studio is also made extensible to allow you to hook into the packaging and publishing process to call your custom MSDeploy providers in the source manifest.

The most interesting pieces is that with IIS Manager and Visual Studio 2010 UI, you will not really need to know all these details, things will just work but I thought it is often interesting to know how things work behind the scenes.

I hope this conceptual overview helps you get the perspective on how web deployment with VS 2010 and MSDeploy will work!!