Web Deploy: IIS6 to IIS7 Migrations + Link Extensions

Recently I was having a conversation with one of Web Deploy (MSDeploy) users and an interesting scenario came up.  He essentially wanted to move his site from IIS 6.0 to IIS 7 and wanted to consider Web Deploy to do this.  In addition he actually was fine with just xCopy-ing the site’s content from IIS6 server to IIS7 server as it was almost 6GB+ in size and trying to create a zip package for it was not most the optimal way of using resources, nevertheless creating a zip package using Web Deploy for just the IIS configuration is what was certainly desirable due to ease of portability & use.

I thought this would be a good opportunity to write a quick note to share with you that migration from IIS 6 to IIS 7 was one of the original scenarios of Web Deploy and so if you are considering the migration from IIS 5.1 to IIS 7 & above then for sure you should consider Web Deploy to help you with it.

Now as you know IIS 6 configuration is based on Metabase and IIS 7 configuration is based on new XML based configuration system so even trying to migrate just the configuration part might be challenging to do manually.  Web Deploy does a fantastic job with this configuration migration and more.

In IIS 7 there is a great UI for you to use to export a Web Site, Web Site or Web Application package from IIS Manager but in IIS 6 there was no way to introduce any UI without servicing IIS 6 which when you consider the impact worldwide is not most ideal thing to do. But anyways the long and short of it is that you will have to use msdeploy.exe command line in IIS 5.1/IIS6 to create a package. When you get the package on to IIS 7+ box then you can of course use the “Import Application” UI on the IIS7 Action pane (right column) even if the package was generated by IIS 5.1 or 6…

One other interesting area to know about is Web Deploy Link Extensions coz they will come very handy when you go about migrating your IIS 6 sites & servers to IIS 7.  Earlier I have talked about how Web Deploy works and what Web Deploy providers are. In addition to Web Deploy providers it is useful to understand the concept of Link Extensions. Well as the name suggests a “Link Extension” is some artifact which Web Deploy can decipher from a parent provider based on some kind of meta data or link which might be present in the parent. Some of the notable link extensions are:

· AppPoolExtension - Application Pool configuration which resides outside the contained site configuration, but again the site configuration points to which Application Pool it uses.

· CertifacteExtension - Certificates which are external artifacts associated to the site but something which site’s IIS configuration links to.

· ContentExtension - Site’s content which resides on the disk but again technically only a pointer to it exists in the site’s IIS configuration.

· FrameworkConfigExtension - The root web.config associated with each .NET Framework (stored C:\Windows\Microsoft.NET\Framework\v4.0.30319\Config) which some IT Admins customize and IIS configuration knows which ASP.NET version you are using so technically that can be deciphered too.

The meta point is that these are all the above link extensions can be turned on or off from Web Deploy command line when you are trying to migrate your IIS 5.1/IIS6 sites and servers to IIS 7 and above… There are more link extensions and it is likely that more might be added in the future, you can keep a link to this TechNet article as that is where we might update the information if it changes.

Finally for the scenario that we started talking about in the beginning of this blog the command line to create a package of all of IIS 6 configuration for a Site (with Site id 1) without including the content of the site would be:

MsDeploy.exe -verb:sync -source:metakey=lm/w3svc/1 -disableLink:Content -dest:package=c:\mySite1Package.zip

If you would like to sync up the entire server then the command line would be:

Msdeploy.exe -verb:sync -source:webserver60 -dest:package=c:\mySite1Package.zip -disableLink:Content

Now the generated MsDeploy package can be easily transported to IIS 7 or IIS 7.5 and configuration can be easily replicated without the content being touched in anyway.

Hope this helps,

Vishal

10 + 20 Reasons why you should Create a Web Package

Before we talk about the reasons why you should create a Web Package let us first understand what is a web package… Web Package is an atomic, transparent, self describing unit representing your web application which can be easily hydrated into any IIS Web server to reproduce your web…  It is a .zip file which not only contains your content but also contains its dependencies like IIS Settings, Databases, GAC DLLs, Registry Keys etc…

The concept of creating Web Packages for deploying your web application to an IIS Web Server is recently introduced with Microsoft Web Deployment Tool (MsDeploy) and towards the end of this post I will talk about how you can create a Web Package for your web app… But before going there let me talk about the 10 reasons why you should consider creating web packages for your web application:

1. Having all your web content and dependencies like IIS Settings & DB into a single .zip file allows you to easily transport it anywhere…
2. If the web package actually contains source code then you can replicate your dev environment to another box relatively easily…  Imagine being able to recreate a project on your home machine by simply emailing yourself a .zip file…
3. If you are deploying in a web farm environment then deploying the web package to various server boxes will allow you to very easily recreate your load balanced web servers…
4. If you are creating software for community to use then sharing web package .zip files with world creates a common handshake model…
5. Web Application Gallery, which will be common home to find reusable Web Applications also uses the same Web Package format… So you will have an opportunity to put up your web app into Web Application Gallery if you create a Web Package…
6. Most of the Package creation process is very automated so you do not need to write custom actions like you would have to do in case of MSIs…
7. Creation of Web Packages can be automated along with your nightly builds really easily using MsBuild with systems like Team Build…
8. You can create a web package for various versions of your web application and easily use the versioned packages to roll back to any version you like…
9. You get free standardized UI to install the Web Packages in IIS Manager which hopefully will become pretty standard and easy for everyone to understand…  If you do not like to use the UI the package can be installed via commandline as well…:-)
10. Most of the automated tools (providers) required for packaging  your web application and its dependencies are available out of the box (few of which are IIS Settings, SQL DBs, Web Content, GAC assemblies, COM components, Registry keys etc)… 

Finally let me mention the out of the box providers which can be invoked when you want to package your web application…  You actually have a choice to call any of these providers depending on what parts of your Web Application you like to be packaged… These are my other +20 reasons why you should create a web package…

1. File System Directory to move a files & folder which contains your web application files like .aspx, .config, images, .js, .css, .master etc – contentPath
2. Creating a new IIS Web Application for your web– iisApp
3. Moving IIS7 and above (read Vista, Win2k8, Win7, Win2k8 R2 and above) Configuration Settings associated with your web (e.g. Default Document, ApplicationPool Mapping etc) – appHostConfig
4. IIS5.1 & 6 (read XP, Win2K3 compatibility)  Metabase Configuration Settings (parallel to IIS7+ settings above) - metakey
5. Pulling data & schema from existing SQL Server Database or custom generated .SQL files which your web uses– dbfullSQL
6. Any Security Certificates (e.g. SSL & ClientAuth) that your web depends upon- cert
7. Any GACed assemblies like 3rd party controls or libraries that your web uses – gacAssembly
8. Any custom IIS7+ Application Pool that your web has created– appPoolConfig
9. Registry key associated with your webs – regkey
10. 32 bit COM Object – comObject32
11. 64 bit COM Object – comObject64
12. Security ACLs associated with folder – setAcl
13. Granular control by pulling just a registry value - regValue
14. ASP.NET root web configuration file on 32 bit machine – rootWebConfig32
15. ASP.NET root web configuration file on 64 bit machine – rootWebConfig64
16. Similar type of support for packaging MySQL DB – dbMySQL
17. Packaging Machine.Config of 32 bit machine – machineConfig32
18. Packaging Machine.Config of 64 bit machine – machineConfig64
19. If there is still a provider missing then you can very easily create one – yourCustomProvider
20. A secret provider which I am not allowed to talk about just yet :-), but trust me it is really a killer provider - secretProvider

So now that you have 10 +20 reasons to create a web package let us talk about how to create one… From end developer/IT pro standpoint you can create Web Packages from various different avenues, some of which are:

• Web Packaging from VS 2010 UI 
• Web Packaging from MsBuild in VS 2010
• Web Packaging from CommandLine
• Web Packaging from PowerShell
• Web Packaging from IIS Manager

Please follow the links above to create a web package using your preferred method… I hope you are jazzed about being able to archive and deploy your web applications using Web Packaging…

Database Deployment with Visual Studio 10

Visual Studio 2010 (VS 10) Beta1 was released recently...  You can download VS 10 Beta1 from Microsoft download page….

Do check out the update on Visual Studio features for Web Developers on our team blog…

We have been discussing about a bunch of deployment features previously and today we will discuss about Database Deployment with VS 10….

VS 10 will allow you to deploy your databases both while creating a web package as well as while publishing directly to a web server provided by your hoster…

To catch up on the previous web deployment posts check out the below links:

Web Deployment with VS 2010 and IIS

Web Packaging: Creating a Web Package using VS 2010

Web Packaging: Creating web packages using MSBuild

How does Web Deployment with VS 10 & MSDeploy Work?

Installing Web Packages using Command Line

Web.config Transformation

 

Apart from the “Package/Publish” tab, with VS10 we will now have a new tab called “Deploy-SQL” in the project properties of Web Application Projects (WAPs)

The “Deploy SQL” tab looks like below:

Firstly let us note that this tab is Build configuration aware i.e. you can configure different settings for “Release” vs “Debug” environment… I have set the configuration to “Release”  and Platform to “Any CPU” for the above example…

TIP:  If you are deploying to a hosted environment then you can create different build configurations per hoster e.g. “DiscountASP” or “OrcsWeb”, this way you can configure various Database deployment settings per hoster…  You can use the same principle for various different database servers you are going to even within your intranet…

Anyways, the first grid on “Deploy SQL”  tab looks like below and actually is a MASTER part of MASTER-DETAIL view of your Database Deployment Settings.  Every Database Entry in the grid below is a representative of a group of database settings representing source and destination database information:

i.e. Database Entry (Friendly Name) = Source Database Information + Destination Database Information

My advice would be to create one entry per every destination database you are deploying to…  The reason why I am emphasizing destination database is coz many folks want to deploy more than one source databases to a single destination database…

One classic example of this is when you are using ASP.NET membership or login features then ASP.NET automatically creates ASP.NET DB in your project AppData directory, apart from this people also like to create a separate ApplicationDB which has the application specific business data.  As you can imagine this results into two different source DBs.  When you are trying to deploy to a shared hosting environment then many times you are paying per database to your hoster and the obvious thought “my ApplicationDB does not conflict with ASP.NET DB in anyway, I am happy to have both of the DBs to go to the same destination DB without paying for two databases”…  In such a situation you would want to create one database entry in the grid above for every destination connection string that you have.

The “Add” button at the bottom allows you to add a “Friendly Name” for your Database Entry…  If you would like to go to more than one destination database you can feel free to add as many Database Entries in the grid above as you want… For simplicity of tracking I would recommend using your connectionString name as the Friendly Name in the grid above.

As you might have already noticed each entry in the grid also has a check box next to it…  The reason why this check box is provided is so that once you configure the database entry then you do not have to completely remove it  by clicking “Remove” button (and loose all the configured data)… If you do not want to include a  particular database Entry (friendly name) in a particular deployment scenario you can simply exclude it by un-checking the checkbox. 

In order to permanently “Remove” the database entry you can select the entry to be removed and can click the “Remove” button….

Let us now take a look at the details of a database entry (e.g details of “productsDB” in the above example).  As I mentioned above the details are going to be broken down into two major categories…

1. Destination Database Information

2. Source Database Information

_____________________________________________________________________________________________________

Destination Database Information: This section looks as below:

It is relatively simple, coz all it contains is connection string for the destination database… Typically when you get a hosted account your hoster will send you the connection string of your hosted database in an email.  This connectionString should go into the above text box.

This field is kept optional and the reason behind it is that if you are using Web Packaging as a model for your deployment and are likely to hand over the web package to your system administrator or someone who will provide connectionString at install time then you can feel free to leave this field empty. 

Do note that if you are directly publishing to a hoster (i.e. not packaging) and you have left this field empty then you will get an error during publishing.

__________________________________________________________________________________________________

Source Database Information: This section looks as below:

The first thing you will see in the Source Database Information is a check box which indicates “Pull data from an existing database” … If you have a local SQL Server database (SQL 2005 or 2008) which you are using for development then this will allow you to extract your database to deploy to the destination database (mentioned in the section above)….

The first setting under “Pull data from an existing database” is Connection string for the source database… This text box is enabled only when you check the check box for “Pull data from…”  You can also click the “…” button next to the connection string text box which will launch the connection String builder dialog as below:

This dialog can help you easily create the connection String for your local database…

The next set of controls under the source connection String text box allow you to determine what kind of SQL Script would like to generate from your source database.  Currently there are two options available…

Schema Only  - Choosing this will only script the schema of your source database

Complete Database – Choosing this will script both schema and data of your source database

On your dev SQL Server it is likely that you might have some test data, in that situation you would want to choose “Schema Only” option which will only pick up the DB schema leaving out the data…  On the other hand if you choose complete database everything from your source database will be scripted…

Insider Note:  VS 10 Database Deployment is using SQL Management Objects (SMO) behind the scenes to script your database…  SMO is a tried and tested API for scripting huge databases… scriptSchema & scriptData are SMO scripting options which Visual Studio is setting when you choose one of the options above…

The next check box is “Exclude object with no schema information” which will give you further fine grain control on scripting your database.  If you do not care about schemaQualify feel free to uncheck this checkbox…

Database Source Scripts -  You might have noticed that in this section there is already an entry called “[Auto-generated Schema Only]”… This entry is added to the source database scripts as soon as you check the “Pull data from an existing database”… At the bottom of Database Source Scripts grid you will notice “Add Script” and “Remove Script” button…  These buttons will allow you to add & remove extra .SQL scripts as your source…

Most of the times developers or DBAs create .SQL scripts to deploy databases…  These custom .SQL scripts can be added and ordered in the grid (and thereby during deployment) using the up and down arrows…  The “[Auto-generated Schema Only]” is a representative of the script that VS will automatically generate from your source database, it is added to the grid so that you can order it up and down along with the rest of the .SQL scripts that you might want to add…

Also note that if you are generating your .SQL scripts via tools like Visual Studio Database Edition (Data Dude) or Red Gate then you can add those scripts here to be included in your web package as well. 

NOTE: There is a way to set up automated build and deployment environment in which you can collect .SQL scripts from Data Dude or Red Gate and provide to VS 10 during web deployment.  I will cover this topic separately in a different blog post…

_________________________________________________________________________________

The last section of the “Deploy SQL” tab is a place for you to provide Database Deployment notes so that you can note specific steps you took or scripts you used while deploying databases; this is purely for your reference purposes…. The deployment notes section looks as below…

Once you have provided all of this information you are good to deploy your databases using Visual Studio 2010 Web Deployment…

Web Packaging  + DB Deployment

After setting up your DB deployment as shown above you can now right click on your project and hit Package –> Create Package as shown below…

The package created as a result will contain your database…  You can read details about creating and installing the web packages below:

Web Packaging: Creating a Web Package using VS 2010

Web Packaging: Creating web packages using MSBuild

Installing Web Packages using Command Line

 

Web Publishing + DB Deployment

Once you set up the DB then not only will it get included in Web Packages but will also be available to be deployed via Publishing…  You can publish you project by right clicking on your project and hit Publish as shown below…

 

I will soon write a detailed post on how to use the new “Publishing” features of Visual Studio 2010…

Hope this information was useful…

-Vishal

How to find Delegated Vs Non Delegated IIS Settings?

IIS Manager has a very nice tool to tell you what features are delegated vs non delegated on the server…  To find out go to Start—>Run –> InetMgr

Now you can click on the server node and then select the “Feature Delegation” as shown below:

On clicking on the feature delegation IIS Manager will show you all the features which are delegated..

In most of the “Read/Write” scenarios when you modify your site settings using IISManager they are written into the application’s web.config file… Although certain features are locked down by IIS Manager and they cannot be changed in your application’s web.config file…

These features are marked as “Read Only” and “Not Delegated”… By default following features are Read/Only and Not Delegated

In Win 7  there is work being done to allow changing Error Pages in the web.config file as well, although up until Win 7 that was not possible…

Hope this helps!!

Web Packaging: Installing Web Packages using Command Line

 

Today I want to advance our discussions around Web Deployment in Visual Studio 10…  To catch up on the previous discussions in this series check out:

Web Deployment with VS 2010 and IIS

Web Packaging: Creating a Web Package using VS 2010

Web Packaging: Creating web packages using MSBuild

How does Web Deployment with VS 10 & MSDeploy Work? 

In this post I will focus on installing the MSDeploy based Web Packages to IIS.  You can actually install/deploy web packages using multiple different avenues listed below:

1. Using IIS Manager UI
2. Using command file created by Visual Studio 10
3. Using command line using MSDeploy.exe
4. Using Power Shell support provided by MS Deploy
5. Using managed APIs provided by MS Deploy

VS 10 will create Web Packages for you based on your settings in the “Publish” tab of the Web Application Projects (WAPs) property pages.  In the Publish tab you also specify the location where you want the package to be created.  In the same “Publish” tab, you also get an option to specify your destination information (i.e. IIS Application Name, Physical Location on the server)…

Check out the section of “Publish” tab below which will give you an idea of the same:

 

After setting all the above information when you right click on your project and click Package –> Create Package then the web package is created at the location specified in “Package Location” setting. To know more read Web Package Creation post.

When you create a package VS creates three files of interest in folder specified by “Package Location” in “Publish” tab; those three files are:

Web Package : The package  itself is produced, which can be either a ZIP file or a folder called “Achieve”.  The choice between .zip vs folder is determined based on your settings in “Publish” tab

Destination Manifest:  This is the file which will allow you to change the destination information at the time of install eg. connection string, IIS Application name etc

Deploy Command File:  VS creates a .cmd file encapsulating MSDeploy command for you so that you don’t even have to type the MSDeploy command while installing the package..

So on your dev box below is what happens:

Now when you want to install the package created all you have to do is to take these three files to the destination server and run the command file.  Typically you can hand out these three files to your server administrator and he/she can run the command on the server (as developers will typically not have access to the servers directly).

In the earlier post we talked about how to create a web package for BlogEngine.Web solution in staging configuration, let us look at how the solution explorer looks like after the package is created:

Notice the package file, destination manifest and the command file in the above image.

If you remember our Package settings while creating the web package; in “Publish” tab we provided Destination IIS Application Name as  “Default Web Site/VS10-Blog”  and Destination IIS Physical Path as “C:\TR8\VS10-Blog”.  If we install the package that is where we would expect the install to go (unless I overwrite it using destination manifest and the deploy command file)

I am now going to emulate a Server Admin and try to install the web package which was handed to me by the developer by going to Start—>All Programs –> IIS  7.0 Extensions –> MSDeploy Command Console (as Admin)

Note: In IIS 5.1 or IIS 6 you can just start regular command prompt and navigate to MSDeploy install location which is typically %Program Files%\IIS\Microsoft Web Deploy

Also note that server admins can very easily automate these process by writing simple batch files.

In MSdeploy command console I will now try to call “BlogEngine.Web.Deploy.cmd”.  I have ensured that the destination manifest, command file and the package are all in the same folder; see the image below:

In MSDeploy Command prompt I can run the VS 10 generated .cmd files in two different modes:

1. /T – This is the Trial run switch.  It will allow your server admin to verify whether your package is not going to do something really bad :-)… But in essence this mode invokes msdeploy in –what if mode which allows you to see what all package will do on the server.
2. /Y – This switch will actually install the package and get it set up on the server.

Below is how my command propmpt looks after running the BlogEngine.Web.Deploy.cmd file with /T switch

Notice the /T switch on the cmd file which in result calls msdeploy in –what if mode…  I truncated the overall out put to show you the final set of information which is “Change Count”…

Now when I run the command file with /Y switch notice that that installation succeeds… And when we go and inspect our IIS you will see that our blog application is correctly created in IIS with below traits:

• Application name is VS10-Blog
• Physical directory for the application is “C:\TR8\VS10-Blog
• Classic .NET App Pool setting that we configured in Step 2: Configure IIS Settings in IIS Manager in the previous blog post is also correctly configured.

If you run this application now, it should be fully functional as well…

If you are trying to automate your deployment process then I recommend using the instructions in MSBuild based package creation post to create your web packages in an automated fashion and eventually use the instructions in this post to go ahead and deploy this web package.

I hope that the above few posts will help you get up and running with web applications using VS 10 Web Packaging support.

Technorati Tags: Web Deployment,Web Packaging,MSDeploy,MSBuild,VS10,Visual Studio,Vishal R. Joshi,Visual Studio 2010

How does Web Deployment with VS 10 & MSDeploy Work?

Web Deployment has taken a huge stride in Visual Studio 2010.   I have started a blog series where I have written about web deployment, you can read more about them below:

Web Deployment with VS 2010 and IIS

Web Packaging: Creating a Web Package using VS 2010

Web Packaging: Creating web packages using MSBuild

 

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!!

 

Technorati Tags: ASP.NET,IIS,IIS 5.1,IIS 6,IIS 7,msdeploy,visual studio,vs10,Visual Web Developer,Vishal R. Joshi

Web Packaging: Creating web packages using MSBuild

 

This post is next in the series of VS 2010 articles that we have been putting together to dive into the Web Deployment improvements with VS 2010 and IIS.  I would recommend reading the the preceding posts to get an overview of all the scenarios supported:

• Web Deployment with VS 2010 and IIS
• Web Packaging: Creating a Web Package using VS 2010

In this post I will cover web package creation using MSBuild command line.  Many medium to large sized teams plan on automating their build process for various good reasons like predictability for QA team, time saving as compared to on-demand manual build, early bug detection with Build Verification Tests (BVTs), knowing the current state of project integration, etc… Many argue that setting up the build system is not worth the trouble for a small project running only a few months; I would suggest otherwise, believe me setting up an automated build process once will pay you back   enough just within a few weeks and will get you into a mode where in the future doing this will be so much more easier… 

Anyways, if you choose to automate your build process there are various tools and technologies available out there, some of the popular ones are:

• MSBuild
• NAnt
• NMake

You can certainly take your build automation process to its best by using Continuous Integration model which we will discuss in subsequent posts.

In anycase, the entire Web Deployment story in VS 2010 uses MSBuild behind the scene which means that all the UI features in Visual Studio are actually wrappers over the underlying MSBuild Targets, Tasks and Properties.  In the previous post we talked about “Creating a Web Package using VS 2010” where we discussed setting up the Package properties in “Package Tab” of the project’s property pages as shown below:

All the properties that you set up in this UI are stored in your .vbproj or .csproj file.  We also talked about this tab being “Configuration” aware, which means that you can set different properties per build environment like Debug, Testing, Staging, Release/Production etc and all of these properties will be saved in your project file.

Now if you would like to create a web package using MSBuild it is much more simpler than you can imagine:

All you have to do is open  command prompt which has MSBuild path preset (e.g. Visual Studio Command Prompt which is available under Visual Studio 2010 –> Visual Studio Tools) and type the below command:

MSBuild "YourFullyQualifiedProjectName.csproj/vbproj" /T:Package

/T:Package is the MSBuild Target named Package which we have defined as part of implementation of the Web Packaging infrastructgure.

Interestingly, when you do not specify any MSBuild target, then for most projects “Build” is the default target hence just providing below command line simply builds your project

MSBuild “YourProject.csproj”

Also note that there can be various dependencies set between targets and our “Package” target has an explicit dependency on “Build” target which means that if the “Build” was not successful then “Packaging” will not even begin, this ensures that during your automated packaging you do not land up spending resources on creating faulty web packages.

By default MSBuild uses the “Debug” configuration but if you would like to create a package for your Staging configuration all you would have to do is:

MSBuild "ProjectName.csproj/vbproj" /T:Package /P:Configuration=Staging

/P:Configuration represents the Property named Configuration which you are setting to Staging…

Diving a tiny bit deeper - If you open your project file in a text editor then you should be able to see all the properties which we talked about from UI perspective in our previous post “Creating a Web Package using VS 2010”…  All these properties will not be visible in the project file until their default values are modified (just a tiny optimization to keep the files smaller and agile :-)). These same properties are optionally settable from command line as well...  Also there are certain properties which are not manifested in the UI or in the project file by default, but are still available behind the scene to provide extensibility and fine grain control that many expect, we will go into the details of those properties in later posts as well.

Anyways, most of the time you should be able to set most of your properties in the UI and use them without much modification in the command line scenario, although it is conceivable that some of the properties may require frequent modification during automated builds e.g. “Package Location”.  Below is a sample command of how you will set up the PackageLocation property along with the Configuration property:

MSBuild "MyProjectName.csproj" /T:Package /P:Configuration=Staging;PackageLocation="D:\Vishal\Package.zip"

When I run the above command then my package for “Staging” configuration will be created in “D:\Vishal\Package.zip”

It is important to note that items passed via command line override the values set in the project file, this ensures that most common values of the properties can be stored in the project file and eventually shared by the entire team…  The ones which need to be momentarily overridden during build time can be set from the command line. 

Also it is good to remember that if you like to pass more than one property to MSBuild command then you can do so by separating multiple properties by semicolon ; as shown above for Configuration and PackageLocation.

The above command line examples can very easily be plugged into automated build systems like CC.Net, TFS, etc, we will look into the process of setting some of these environments in later posts as well.

For now, I hope you will be able to envision the prospects of creating these Web Packages in an automated fashion and share them across your teams on regular basis.

Technorati Tags: Web Deployment,VS 10,Visual Web Developer,IIS,ASP.NET,Cruise Control,TFS,Team Build,MSBuild,NAnt

Web Packaging: Creating a Web Package using VS 2010

In the earlier post I highlighted various investments that we are making in Visual Studio 2010 and IIS to make Web Deployment easier.  You can read that post below:

• Web Deployment with VS 2010 and IIS

Deploying a web project with all its correct dependencies is not a trivial task. Some of the assets which need to be considered during deployment are:

• Web Content (.aspx, .ascx, images, xml files, PDBs, Binaries etc)
• IIS Settings (Directory browsing, Error pages, Default Documents etc)
• Databases that the web project uses
• GAC Assemblies and COM components which the web project depends upon
• Registry Settings that may be used within the web project
• Security Certificates
• App Pools

In an enterprise environment a web application with all of its dependencies needs to move across various environments before being finally being deployed to a production server.  A typical set of transition servers are development, testing/QA, staging/pre-production and production.  Also on the production environment there are web farms where these webs need to be replicated.  Today doing all these things is more or less a manual process and involves a tons of documentation that both developers and server admins have to deal with.  Even with all the documentation the steps are certainly very much prone to errors.

To aid all these scenarios we are introducing the concept of  a "Web Package". Web Package is an atomic, transparent, self describing unit representing your web which can be easily hydrated onto any IIS Web server to reproduce your web.  VS 2010 uses MSDeploy  to create the web package from your web application.

In today's post I will be primarily focusing on creating a web package from VS 2010 which has IIS Settings as well as web content.

The package created by VS can be installed using UI in IIS Manager as well as command line, we anticipate that developers eventually will give the web packages to server administrators who will be able to inspect/verify the package and then install them on the server...  I will cover package installation topic in subsequent post...  But for now let us learn how to create a web package

Step 1: Configure your Web Application Project (WAP) to use IIS Settings

For this discussion we have BlogEngine.Web downloaded from codeplex and converted it into a WAP.  Then this project was opened in VS 2010  and the VS10 migration wizard moved the project into VS10 format.  Thanks to the multi-targeting  features in VS 2010 which can support .NET versions 2.0 till 4.0; hence it is up to you which Framework version you want to run your web against.    I have also configured this blog application to use IIS Web Server for development (Learn how to do so by clicking here). 

At the end of this step my solution explorer looks as below:

Step 2: Configure IIS Settings in IIS Manager

Most IIS 7 web applications use IIS integrated pipeline which is configured with "Default App Pool" of IIS.  Blog Engine .web does not use integrated mode and will throw an error shown below if made to run under "Default App Pool".

To get rid of this error I changed the App Pool of this application to "Classic App Pool" (Learn how to do so by clicking here) and then the application runs great as shown below:

App Pool mapping is just one of the IIS setting which your app may use, there are various other IIS Settings which you can configure using IIS Manager (e.g. Default document, Error pages etc etc); all of these settings are relevant based on your application scenario... The good news is that VS 10 & MSDeploy will auto detect all the changes you make to the default IIS settings and pick it up for deployment...

Essentially, at the end of this step you should have your web application up and running with all the IIS settings configured in IIS Manager. 

Step 3: Configure Package Settings

In VS 2010 we have introduced one additional property page for WAPs called "Publish" as shown below:

Let us look at various properties of the this tab to understand how it works:

Configuration Aware Tab: Note that the Publish tab is build configuration aware:

• The Publish tab is made configuration aware as deployment settings tend to change from environment to environment; for e.g. many a times developers want to deploy their “Debug” configuration on a Test Server and include PDBs as part of this deployment. When the same web is deployed in “Release” configuration on a production server the deployment may exclude PDBs.  (Learn how to manage build configurations by clicking here)

Items to Package/Publish – This section will help you decide what type of content you would really like to package/deploy.

• Types of Files: By default this option is set to "Only files needed to run this application" .  This is usually sufficient for your deployment as it includes all the files from your project except source code, project files and other crud files not required to be deployed...  But apart from that there are two additional options available as shown below...

"All files in this project" and "All files in this project folder" options are very similar to what Publish WAP options were in VS 2008...  I had written an earlier post explaining these options here...  In subsequent posts I will also dig into various other interesting ways of using these options.

• Exclude Files from App_Data folder – “App_Data” folder is a special ASP.NET folder where many developers like to put their SQL Express DBs (.mdf/.ldf files), XML files and other content which they consider Data. In many situations on production web server a full version of SQL Server is available and using SQL Express is not all that relevant. In such scenario (and for the corresponding build configuration e.g “Release” ) a user can check the “Exclude Files from App_Data”.
• Exclude Generated Debug Symbols – It is important to understand that generation of debug symbols is different from deployment of the same. This check box will tell VS 10 whether you would like to package/deploy the already generated Debug Symbols (Learn more about deploying debug Symbols here). 

Package Items

 

• IIS Settings  - Checking this checkbox informs VS10 that you are ready to take all of your IIS Settings configured for your application in IIS Manager as a part of your web package.  I am glad to tell you that IIS 5.1, IIS 6 as well as IIS 7 environments are supported as part of this feature hence whether you are working on XP, Win2K, Win2K3, Vista or Win2K8 you should have no issue with packaging IIS Settings...  

These setting includes the "App Pool mapping" your web is configured to run against (e.g. "Classic App Pool" mapping discussed in Step 2)

• Additional Settings -   The items in this grid are advanced properties.  It is still good to know about these coz it impacts what will be included in your package.  Most of the properties in this grid are related to the entire server and not just to your application so you should use them very carefully. 

Currently VS10 only displays "Application Pool Settings" but behind the scene it is possible to configure VS10 to support packaging root web.config, machine config , security certificates, ACLs etc...  

I wrote a small tips & trick about differences between Application Pool Mapping and Application Pool Settings which will help clarify the implications of such advanced settings; you can read more about it here.

Package Settings

• Create MSDeploy Package as a ZIP file - This checkbox allows you to decide whether you would like to create your web package as a .zip file or as a folder structure. If you are concerned about the size and are moving the web package around very often then I can see you using .zip format for the package; on the other hand if you care to compare two packages using diff commands (either of source control or independently) then I can see you using the folder format.
• Package Location - This is an important and required property as it defines the path at which Visual Studio will place your web package. If you choose to change this path make sure that you have write access to the location. Do note that the Package Location is modified based on whether you choose to create the web package as a .ZIP file or vs a folder structure.
• Destination IIS Application Path/Name - This property allows you to give IIS Application name that you will use at the destination Web Server.
• Destination Application Physical Path - One of the most important information which is embedded inside the web package is the physical location where the package should be installed. This property allows you to pre-specify this embedded information.  You will have an opportunity change both IIS Application Physical Path as well as Application Name at the time of deployment but in this property page you are given an opportunity to choose a default value.

Step 4: Create the "Web Package"

This is the last step in creating the web package and the simplest too...  The idea is that once you configure the above settings creating a package should be easy; in fact even if you do not go to the "Publish" tab we have tried to set smart defaults so that in most normal circumstances creating web package should be just the below two steps:

• Right Click on your "Project"
• Click on Package --> Create Package

Once you click on this command you should start getting output messages around your package creation pumped into your output window... 

When you see “Publish Succeeded” as below in the output window then your package is successfully created.

 

To access the package go to the location specified in the “Package Location” textbox. By default this is in obj/Configuration/Package folder under your project root directory (Configuration here implies Active Configuration like Debug/Release etc).

Note: "Create Package" command creates web package only for Active configuration. By default “Debug” is the active configuration inside Visual Studio. If you would like to change the Active configuration you can do so by using Build --> Configuration Manager as described here. You can certainly set properties for all available configurations by switching the configuration on top of the “Publish” tab but that action does not change the Active configuration

 

Finally, you can also automate creation of web packages via your team build environment as everything discussed above is supported via MSBuild Tasks.  In subsequent posts we will get into the details of these areas too...

Hope this helps...

Technorati Tags: Visual Studio 2010,VS 2010,VS10,Vishal R. Joshi,Web Packages,MSDeploy,Web Deployment,IIS,IIS 7,IIS 6

Tips & Tricks: Difference between App Pool Mapping Vs App Pool Settings

Application Pool is an IIS concept and will apply to an application which uses IIS as its web server.  Learn how to make your web application to use IIS during development time by clicking here...  If you application is an IIS based application then you should be able to look at its basic settings as below:

In this post I quickly wanted to discuss about the difference between App Pool Mapping and the actual App Pool Settings

• App Pool Mapping - This is a setting limited to your web application in IIS...  This instructs IIS to identify the correct App Pool which your web application should run against.  It by no way changes any settings associated with the App Pool itself i.e. you are using an app pool which was pre-created/configured and essentially the settings of those app pool will now apply to you web application too...  I had earlier written a quick tip on how to change the App Pool used by your application which you can find here...
• App Pool Settings - App Pool settings are stored in separate configuration file in IIS and they are manifested in IIS Manager UI as below:

You can create, edit, delete App Pools for the machine using the above options... Although the important point to note is that the same app pool can be used by various applications on the same server and changing an App Pool setting will impact all the applications running on the server.

In anycase, if you would like to modify the App Pool Settings you can do so by clicking the "Edit Application Pool" settings as shown in the diagram above

Some of the Advanced settings which can be modified for an application pool are as shown in the figure below:

So in nutshell, it is important to understand that when you change app pool settings on your developer box then they will not automatically reflect on the server unless it is explicitly modified.

Also the reason why server admins are reluctant to modify a particular app pool's settings on the server is coz it may impact many other applications on the server who are using the same app pool. 

Some server admins create different app pools for different webs to ensure that other applications on the server are not impacted by individual application change requests to the app pool.

Hope this helps...

Technorati Tags: IIS,IIS 7,App Pool,Application Pool

Tips & Tricks: How to change the App Pool which is used by your web application

If you would like to use advanced IIS features and configuration on your development machine then you first need to make your web application use IIS Web Server for development.  You can do so as described below:

• Tips & Tricks: How to use IIS as your local Web Development Server...

Once you app is using IIS you can go to IIS Manager by going to Start --> Run and typing Inetmgr... In IIS Manager navigate to your application (which will be typically under "Default Web Site")

Now click on the "Basic Settings" as shown below and change the app pool by clicking the "Select"  button:

All the available app pools on your machine will be shown in the select drop down as below:

e.g. Default App pool to use IIS Integrated Pipeline (Learn more by clicking here), Classic .Net App Pool for non integrated mode...

Hope this helps...

Technorati Tags: IIS,App Pool,Integrated mode,WAP,Inetmgr,VS 2010,Visual Studio 2010,Visual Studio

Tips & Tricks: How to use IIS as your local Web Development Server...

When you create a new web application project (WAP) by going to File --> New --> Project --> Web Application Project then the default Web server used is "Visual Studio Development Server"  (fondly named as 'Cassini')...

Cassini does not require you to run as a local administrator on the dev box and hence is something which is preferred by a lot of enterprises.  At the same time Cassini is not an exact representation of how your production web server will look like.  As your production web server is typically an IIS Web Server, Visual Studio also allows you to use IIS as your development web server...

Although many operations related to IIS require you to be a local administrator of your box...  If you would like to use IIS as your development web server than you need to make sure you are running Visual Studio in an administrator mode.

After you do so, you can right click on your WAP --> Click Properties and open the Property pages of the project.  Now you can navigate to the "Web" tab of the property page and select "IIS Web Server" as shown below...

You can then click the "Create Virtual Directory" button and your IIS application + VDir will be created... Going forward when you debug or run the Web Application from Visual Studio then your application should use all of the IIS Settings that you configure using IIS Management Console (Start --> Run --> Inetmgr)...

Note: Do note that Visual Studio uses IIS Metabase Compatibility mode to actually access IIS functions so you need to go to Start --> Control Panel --> Programs & Features --> Add or Remove Windows Components / Turn Windows features on or off and make sure below features are enabled:

Hope this helps...

Technorati Tags: ASP.NET,IIS,IIS6,IIS7,Visual Studio 2010,VS,VS 2010,VS 2008

Web Deployment with VS 2010 and IIS

Today, deploying a web application is not as easy as it should be. Whether you are deploying your web to a shared hosting environment and paying monthly to maintain it OR whether you have a web server/s managed by your enterprise, there are a lot of manual steps involved in getting your application from point A to point B.

If you are deploying your web application to a shared hoster then today you have to use technologies like FTP which take a long time to get your web content to the hosted server. After deploying your content you have to manually go to hoster control panel and install your database by running sql scripts and configure various IIS settings like marking a folder as an application to isolate it from the rest of the application.

If you are in an enterprise environment and you want to get a web application deployed you have to systematically document each step that your server admins and DBAs have to perform. In most circumstances you also have to ask your admins to modify the web.config files and go to IIS Manager and configure your settings apart from deploying your web content. Your DBA has to do the necessary steps of running the sql scripts in the right order to get your DB up and running. Such installations many a times take hours to complete.

With Visual Studio 2010 and IIS Web Deployment Tool (MsDeploy.exe / Web Deploy) we are introducing a set of technologies which can seamlessly deploy your applications taking care of the problems stated above. Microsoft Web Deployment Tool is a free download available on the web… You can download MSDeploy from below location:

http://blogs.iis.net/msdeploy/archive/2008/10/29/the-web-deployment-tool-beta-2-is-now-available.aspx

Do note that installing Visual Studio 2010 will automatically install MSDeploy for you. Visual Studio 2010 CTP can be downloaded from below location:

http://www.asp.net/vwd/

Web Deployment feature sets in VS 2010 can be broken down into following major areas:

1. Web Packaging - VS 2010 uses MSDeploy to create a .zip file for your application which we call as a web package. This file contains meta data + the below artifacts

· All of your IIS Settings (e.g. application pools, error pages etc)

· Web Content (e.g. .aspx, .ascx, .js, images etc)

· SQL Server DB

· Various other artifacts like Security Certs, GAC Components, Registry etc

A web package can then be taken to any server and installed either via IIS Manager UI Wizard or even via command line or API for automated deployment scenarios.

2. Web.Config Transformation – With VS 2010 web deployment we are introducing XML Document Transform (XDT) which will allow you to transform your development time web.config file to production/deployment time web.config file. The transformation is controlled by web.config TRANSFORM files named web.debug.config, web.release.config etc. The naming of these files is tied to the MSBuild configuration you are trying to deploy. The transform file will need just the changes that you really want to make to your deployed web.config… You can control the type of changes by instructing the XDT engine using simple and easy to understand syntax…

e.g. the below syntax in web.release.config will replace the connectionString section with new values in the web.config file which is produced for deployment of your release configuration.

3. DB Deployment – VS 2010 allows you to deploy your application along with all of its dependencies including database dependencies on SQL Server. Just by providing the connection string of your source database VS10 will automatically script its data/schema and package it for deployment. VS will also allow you to provide custom .sql scripts and also sequence them correctly to run on the server. Once your DB is packaged along with your IIS Settings and web content you can choose to deploy it to any server by providing the connection string at the install time.

4. 1-Click Publish - VS 2010 will allow you to not only package your web applications with all of its dependencies but also use IIS remote management service to publish the application to remote server. VS 10 will now allow you to create a publish profile of your hoster account or of various testing servers and save your credentials securely so that going forward you can deploy to any of these publish profiles with just one click using Web One Click toolbar. With VS 10 you will also be able to publish using MsBuild command line so that you can configure your team build environment to include publishing in continuous integration model.

To learn in further details about these technologies please view the videos here.

ALSO MAKE SURE YOU VISIT THE OVERVIEW POST FOR WEB DEPLOYMENT…

Technorati Tags: Web Deployment,Visual Studio 2010,ASP.NET,MSDeploy,VS 10,VS 2010,ASP.NET 4.0,.NET 4.0,WAP,Web Application Projects

Web Deployment with VS 2008

On July 21st 2006, during ASP.NET Insider summit I had a chance to do a podcast with Wally McClure...  We discussed a bunch of items around Web Deployment with .NET 3.5 and VS 2008...  Some of the topics covered in the podcast are:

General Web Deployment Scenarios

Web Application Projects vs. Websites

Pre-compiling Web Projects (aspnet_compiler.exe)

Merging Web Projects (aspnet_merge.exe)

Web Setup Projects (MSI files)

Web Deployment Projects (WDP)

Microsoft Deployment Tool (MSDeploy.exe) 

Sql Publising Wizard

 

You can view the podcast at: http://aspnetpodcast.com/CS11/blogs/asp.net_podcast/archive/2008/07/25/asp-net-podcast-show-120-deploying-web-applications-with-vishal-joshi.aspx