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

VS 2010 Beta 2 Read Me Items for Web Deployment

There are some known issues/bugs related to VS 2010 Web Deployment features in VS 2010 Beta 2 Read Me… I can imagine reading the entire Beta 2 read me file can be daunting so I thought I can just copy paste the ones related to Web Deployment here…

DB Deployment will fail if the Database Name is longer than 127 characters

Description: If you are using latest VS 2010 Web Deployment Features and trying to deploy your database using the Deploy SQL property page then at times you might get error from VSMsDeploy task. 

There might be several reasons for the failure including connection and authentication issue but a current bug in the product does not allow you to script schema/data from a database (typically SQL Express MDF file) if the file path is longer than 127 characters.  In the OS like XP or Win2K3 the default path for the VS project & its default ASP.NET Login/Profile DB could be something like C:\Documents and Setting\... \Visual Studio 2010\Projects\MyProject\App_Data\ASPnet_DB.mdf... This path can potentially exceed 127 characters and result into Deployment failure...

Workaround: The easy work around is to have the project copied to a location where the path will not exceed 127 characters for e.g. C:\MyProject\App_Data...  This issue will eventually be resolved in the product...

Some VS 2010 Web Deployment Features will not work if VS 2010 is installed on Vista RTM instead of Vista SP1

Description:  If you are using the new Web Deployment feature set in VS 2010 and are using the below features which integrate with MSDeploy:

• Web Packaging
• One-Click Publishing
• DB Deployment

then you will have to use Vista SP1 instead of Vista RTM as your OS.

Workaround: MsDeploy requires features which are built inside Vista SP1 and hence trying to run Web Deployment features on Vista RTM fails.  This is a required dependency so you will have to use Vista SP1 as your OS for VS 2010.  Do note that you can still use any other operating system like XP, Win2K3, Win2k8 R2, Win7 etc to install VS 2010 and use the Web Deployment features, it is just advised that any of the OS versions that you use are updated with the latest Service Packs so that all the required dependencies are in place.

MsDeploy.exe.config file will be required to run Web Deployment on machines with .NET 4.0 only

Description: If you installed VS 2010 on a clean machine which does not have .NET 2.0 (e.g Win2K3)  and are trying to use the VS 2010 Web Deployment Features then when you run the deploy.cmd file to install your web package you might receive error stating "Msdeploy.exe -.NET Framework Initialization Error Unable to find a version of the runtime to run this application."  This is due to the fact that VS 2010 comes with only .NET 4/CLR4 and and CLR 4 does not allow CLR 2.0 executables to run  without having an explict exe.config file…  If you are using other .NET 2.0/3.0 or 3.5 exes on a box with just .NET 4 then you might face similar issues with those EXEs too…

Workaround: You can easily work around this by going to "%Program Files%\IIS\Microsoft Web Deploy" (& additionally also on "%Program Files (x86)%\IIS\Microsoft Web Deploy" folders and create following msdeploy.exe.config file in there

<configuration>
    <startup useLegacyV2RuntimeActivationPolicy="true">
            <supportedRuntime version="v2.0.50727" />
            <supportedRuntime version="v4.0" />
    </startup>
</configuration>

This issue will be fixed in the future releases of the product.

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

Importing a Web Package into IIS Manager

Today I am hoping to talk about installing/importing a Web Package into IIS using IIS Manager…

For this walkthrough you will first need a Web Package… If you want to get few ready made packages you can get them from Web Application Gallery…  There is also a MsDeploy package of BlogEngine.NET available on CodePlex, which you can download to try out this walkthrough…

Hopefully, eventually you will be creating your own web packages for deployment and this walkthrough will even apply at that time…  If you want to learn how to create a web package from Visual Studio 2010 then read the below posts:

• How to create a web package from VS 2010
• How to create a web package using MsBuild commandline
• How to include SQL DBs within your web packages 

To begin importing a web package into IIS using the new “Import Application” wizard you need to make sure that you have installed IIS Manager by going to Add/Remove Windows component…  You will also need MsDeploy installed over IIS, typically it will come with your VS 2010 installation but if you do not have VS 2010 just yet then you can download it from MsDeploy Download.

Today, I will install a Web Package of the sample ASP.NET 4.0 web application that I created earlier in the tutorial “Creating a simple ASP.NET 4.0 Web Site”…

To start importing the web package let us start IIS Manager (Start –> Run –> InetMgr)

I will be installing the web package under Default Web Site…  Although it is not required to install the package under Default Web Site, it can be installed under any Web Site of your choice… Also if the package created was a “IIS Web Site Package” then it could be installed under the server /sites node directly as well…  In anycase when we open the “Default Web Site” node then on the right side command bar you will now notice two new commands  1.) Export Application 2.) Import Application as shown below:

On clicking “Import Application” on the first screen you will be asked to provide the path to web package (.zip file)… I will be providing the location of the sample web package which I created in the earlier tutorial:

On clicking next the Import Application wizard will display the content of the web package as below:

Notice that in the above example the package wizard shows that the Web Package contains:

1. IIS 7 Application - This will actually do the job of creating an IIS Application and mapping the virtual directory…  It will also move any additional IIS Settings associated with the web application…
2. File System Content  - All the physical files (.aspx, .dlls etc) which need to be placed in the web site directory…
3. Database – This is the database that I packaged into my web package

On clicking “Next” I will get a screen which I will call as the “Parameters” screen…  When you create a package using VS 2010, then VS identifies the key attributes of your web application which you need to customize and it creates MsDeploy parameters for the same…  All these parameters are something which you can modify during the package import process as seen below…
In the above example notice that “Default Web Site” is read-only… This is due to the fact that the “Import Application” wizard was invoked from Default Web Site… I am now naming the Web As “SimpleASP4Web” and placing it under “C:\WebSites\SimpleASP4Web”…  Also note that I am using “SimpleASP4Web” DB on my local SQL Server…

The ConnectionString that I am providing in here will be used to deploy my packaged DB and will also be used to update my web.config file (this will happen only if the package was created to do so…  I will write a separate blog post on how to do that, but in future release of VS 2010 this option will be set by default when you create the web package at the first place…)

In any case now on clicking “Next” the Web Application installation will begin showing you a progress bar and hopefully within no time the web package will get installed showing you the status as below:

On hitting “Finish” on this screen the web package will be installed and on inspecting the IIS Manager you can see that the package is actually successfully imported and web site is ready to go:

On inspecting the SQL Server Management Studio you can also see the Simple ASP4Web DB also installed:

Hopefully you can see that the web deployment features with great UI options in VS 2010 and IIS will make the process of packaging and installing you web applications much easier than what it has been before…

-Vishal

Web 1-Click Publish with VS 2010

Visual Studio 2010 has great features to make your web deployment easier…   I have written a high level article describing the web deployment feature set of VS 2010 below:

• Web Deployment with VS 2010 and IIS

Today my goal is to go through an end to end walkthrough of the Web 1-Click  Publish feature of VS 2010…  This walkthrough will cover following:

• Prepping up an ASP.NET 4.0 web application which is using a SQL Server Database for deployment
• Gathering the remote web and database server information
• Setting up Web.config Transformation to change your connectionString
• Including SQL Server Databases in Web Deployment
• Creating a 1-Click Publish Profile to Publish your web content, databases and transformed web.config files
• 1-Click Publish your Web Application

For this walkthrough you will need Visual Studio 2010 Beta1 which you can download FOR FREE from http://www.microsoft.com/visualstudio/en-us/products/2010/default.mspx

Let us get started…

Prepping up an ASP.NET 4.0 web application which is using a SQL Server Database for deployment

In this walkthrough we are assuming that you already have a web application which uses SQL Server database and you are ready to deploy it to remote web server and database server…  If you do not have such a web application then I encourage you to follow the simple step by step instructions in the walkthrough Creating a simple .NET 4.0 web application using Visual Studio 2010…

With the assumption that you now have a data driven ASP.NET 4.0 web application let us try to understand what all is needed to be taken care of while deploying such a web application… Things that you need to take care of during such typical deployments are:

1. You need to modify the connectionStrings in the web.config file to point to the remote SQL database server instead of the local SQL Server Express that you are using on your dev box…
2. You need to deploy your databases to the remote SQL database server
3. You need to deploy all of your master pages, content pages, images etc to the remote web server

In the remaining portion of this walkthrough you will see how to accomplish all of the above things…

But before getting to that, let me introduce you to Web Application we are about to deploy… The solution explorer of this web application looks as below:

Notice that this web application has 1-ClickPublish.mdf file in the App_Data folder…  Also notice that it has a Site.Master, Default.aspx and Address.aspx Web pages…  When you run Default.aspx it looks as below:

The top banner of “Visual Studio 2010 Web 1-Click Publish” is coming from Site.Master…  The grid containing FirstNames & LastNames is being populated from the 1-ClickPublish.mdf file…  The “View Addresses” button takes you to “Address.aspx” page which shows the addresses of the people on “Default.aspx” as shown below:

The web.config file of this web contains connectionString named “1-ClickPublishDB” which points to the SQL Server express database (1-ClickPublish.mdf )…

Gathering the remote web and database server information

Before we begin to deploy the web application to the remote server we will need to gather the information of the destination servers… Typically if you are going to a shared hoster then this information is provided to you in the welcome email from your web hosting company…  Web hosters typically have various plans which include database as well as web server storage space….

If you are not planning to go to web hosting company but rather are interested in hosting your own web and database servers then you will have to follow some more additional steps to set up your web servers and database servers…  I am not covering this in the current walkthrough but will cover the same in subsequent walkthroughs…  But for now let us assume you have a web hoster who has provided you with the information required for deployment…

Typically web hosters will ask you which .NET Framework version you would like to target (i.e. 2.0, 3.0, 3.5 or 4.0)… Based on the .NET Fraemwork version you choose your web site will be provisioned with the correct Application Pool… For .NET 2.0, 3.0 and 3.5 the Application Pool targets CLR version 2.0… For .NET 4.0 the Application Pool is set to CLR version 4.0…. It is very likely that your .NET 2.0, 3.0 or 3.5 web application will run seamlessly on .NET 4.0 but it is still required to talk to your hoster to change you Application pool from .NET 2.0 to .NET 4.0… 

If you register for a hosting plan which supports the new VS 2010, ASP.NET 4.0 and Microsoft Web Deployment Tool (MsDeploy) then you will receive below pieces of important information which we will use later during the walkthrough… In the rest of the walkthrough I will refer to these as “1-Click Settings” so that you can easily relate to this section…:-)

• Service URL:  This URL is in the format https://myWebServer:8172/MsDeploy.axd and actually points to a IIS handler which will manage your deployment on the remote web server
• Site/Application Name: This is the name of your IIS Web Site on the remote web server…  This is where your application will be deployed…
• UserName: This user name is the account which has the access to the ServiceURL and your Site on the remote web server
• Password:  The password which you use for your above UserName
• ConnectionString: This is the ConnectionString to your remote database server… Typically your hoster will make sure that your remote web server and remote database server have the correct ports opened so that your web application can easily consume the data from your database…

At this time I am assuming that you have your web application ready to be deployed and you already have the above pieces of information from your web hoster…  The next thing we will do now is to set up web.config transformation to modify your web.config file during deployment….

Setting up Web.config Transformation to change your connectionString

Let us assume that you are using “Release” build configuration when you are deploying to a remote web server…  You can create and use a different build configuration as well but I am choosing “Release” as it comes out of the box with VS 2010…  Learn more about Managing Build Configurations… 

By default “Debug”  is the ‘Active’ build configuration… As we are ready to deploy to a hoster you can change your Active build configuration to “Release”… You can do so by simply changing the drop down value on the VS “Standard” toolbar as shown below:

Alternatively you can also change the build configuration by going to the Build –> Configuration Manager menu…

After this step your Active Build Configuration should be “Release”…  You can now open up the node next to the web.config file to reveal web.debug.config and web.release.config as shown below:

In case of VB.NET you will have to click the top right button to “Show all files” to see the dependent web.release.config…

Now open the web.config as well as web.release.config files and copy the connectionString section from the web.config file into the web.release.config file as shown below…

FROM

TO

Now you need to do two quick things

1. Just simply write xdt:Transform=”Replace” in the connectionString node of web.release.config as shown below…
2. Also change the connectionString attribute by putting the value that you got from the hoster (the one we referenced in “1-Click Settings” )… Let us say my hoster proived me with connectionString as “Data Source=myHostedSQLServer;Initial Catalog=myhostedDBName; User ID=VishalRJoshi; Password=*VS10Rocks” then my web.release.config should look as below…

Also note that by default Web.Release.config has a transform called “RemoveAttributes” to remove the debug attribute when you are going to the “Release” environment…  Many hosted environment will not allow you to have debug=true coz it is not safe hence removing the debug attribute is required…

With this you have set up the automated web.config transformation which will take care of changing your connection string during every deployment… !! There is a lot more you can do with XML Document Transforms (XDT)…  Check out the different possibilities Web.Config Transformations by leveraging XDT here…

Including SQL Server Databases in Web Deployment

As the current web application is actually using the data in 1-ClickPublish.mdf it is required to move the database schema and data from this local SQL Server Express database to remote hosted SQL Server database server… In order to make that happen you need to go to “Deploy SQL” tab of the Project properties…

You can open project properties by double clicking the “Properties” item under the project node as shown below:

When project properties window opens then navigate to “Deploy SQL” tab…Once you open “Deploy SQL” tab you need to do following quick things:

Make sure you are using the “Release” configuration as that is the configuration we are going to deploy (and you also have web.config transformation for Web.Release.config)…

Click “Add” button and give a friendly name for your database deployment as shown below: (I would recommend using the name that you used for your connectionString – for secret reasons I will talk about in future posts :-))

Next you will have to configure the “1-ClickPublishDB” settings which you just created by clicking it…  As soon as you click it the disabled section below will light up which you need to fill in as shown below…

The key points to note while filling up the DB Deployment information above are:

• ConnectionString for the destination database is the connectionString which you received from hoster in an email (the one we referenced in “1-Click Settings” )…
• “Pull data from an existing database” will instruct Visual Studio 2010 to extract data from the local SQL Server…
• The connection string below the “Pull data from…” checkbox represents the source database (which is on your local dev box)… This connection string can be found in the original web.config file of your web application as the datasource controls you used insert the connectionString in web.config file…
• The “Complete database” radio button instructs Visual Studio 2010 to script both database schema as well as data from your database…  If you contain junk data that you do not want to deploy to the server then choose “Shema only” option…

With these settings you can now hit save on top of Visual Studio and you have configured your database for deployment as well…Hopefully that was not too hard :-)  If your needs are more deeper than the above then there are many other powerful Database Deployment options which I have discussed in DB Deployment post earlier…

Creating a 1-Click Publish Profile to Publish your web content, databases and transformed web.config files

Now that you have set up web.config transformation and also set up you database deployment settings, it is time to create a 1-Click Publish profile to use for your deployment…

You can do so by Right clicking on your project node and hitting “Publish…” as shown below:

With that you will get the “Publish Web” dialog which you can fill as below:

I have specially numbered the fields above so that you can easily relate to them in the text below:

1. Publish Profile Name-  I have named it as myWebHosterName you can name it with the destination name that you can easily remember…  Usually if you are going to a web hoster then naming this as something like “DiscountAsp” or “OrcsWeb” would be advisable…
2. Service URL:  As we discussed in the “1-Click Settings” section at the beginning of the post, this is provided to you by your hoster…  This URL associated with the Publish Method “MsDeploy” which is used behind the scenes by Visual Studio 2010 to Publish your entire web… You can learn more about the way MsDeploy works in one of my previous blog posts…  Also while you are at it note that the new “Publish” dialog also tells you the Build Configuration that you are publishing (i.e. the Active Build Configuration), in our situation we are using the “Release” configuration for which we have set up the DB Deployment and Web.config transformation…
3. Site/Application Name: As we discussed in the “1-Click Settings” section at the beginning of the post, this is also provided to you by your hoster…  If your hoster provided VishalRJoshi.com as your Site name you can feel free to append a folder name underneath it e.g. VishalRJoshi.com/Blog…
4. Mark Folder as IIS Application on destination: If you choose to Publish to a folder under the parent site eg “VishalRJoshi.com/Blog” AND  want to have separate session state, cache etc functionality for that subfolder then you will have to convert that folder into an IIS Application underneath your parent web site…  This checkbox will allow you to achieve that easily in an hosted environment… This is a the additional IIS enhancement that was made as part of “MsDeploy” Publish Method, so we hope you will like it…:-)
5. Allow untrusted certificates-  MsDeploy Publish method will only take https:// URLs… As you know that secure http requires a SSL certificate but it is understood that it will not be possible to always buy a certificate from authorities like VeriSign etc and especially if you are deploying within your team environment then expecting a fully signed certificate may not be rational, hence this option allows the web server owner to provide a self signed SSL certificate… Although, in general it should be understood that checking this box increases threat on the data which is being transferred over the wire…
6. User Name, Password and Save Password:  Again, As we discussed in the “1-Click Settings” section at the beginning of the post, User Name and Password is also provided to you by your hoster…  “Save Password” is a feature in VS 10 which will securely save your password, so that you do not have to keep typing it again and again…
7. Save -  Now you can hit the Save button on the top, to save the “Publish Profile” you just created…
8. Close – Close button will allow you to close the “Publish Web” dialog

After doing all of the above you have configured your Web Application for 1-Click Publish going forward…

1-Click Publish your Web Application

For your convenience Visual Studio 2010 offers Web 1- Click Publish toolbar as shown below:

You can enable this toolbar (if not visible) by going to View—>Toolbars—> Web One Click Publish… You can now simply click the Publish button below after every little change you make to your project that you want to deploy… 

This way you can keep updating your web at the destination with ease…  Do note that you are allowed to have upto 50 Publish profiles per project, which can allow you to Publish the same project to 50 different web servers in just clicks (I hope 50 should be enough, if not let us know now and we will be happy to bump that up :-))…

NOTE:  If you are incrementally publishing you web then you should go to “Deploy SQL” tab and uncheck your database deployment… If you do not do so then your Publishing will fail as MsDeploy intentionally does not overwrite the database that you already have on the server…  There is a easy fix to change that behavior i.e. there is an option to delete database every time you republish, but I will refrain from mentioning it until someone asks as that is purely a Test server scenario… :-)

Checking your deployed Web

With all of the above steps you are good to hit the “PUBLISH” button…  Once you hit the button your web should get deployed to the hoster much more quickly and reliably than ever before…

With all this you are now set up to have 1-Click Publish of your web application from Visual Studio 2010…

In later posts I will share the Performance and Scalability numbers of MsDeploy Publish method too but as far as I can tell MsDeploy publish is quite more reliable and performant than most other traditional web publishing mechanisms…

I hope this walkthrough will help you experience the new powers of Visual Studio 2010 and Microsoft Web Deployment Tool…

If you would like to learn more about Web Deployment with VS 2010, then I have explained a bunch of other features in the posts below:

• 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
• DB Deployment with Visual Studio 2010

Hope this walkthrough is helpful

-Vishal

Some KB Items:  There are certain known issues and workarounds which you may or may not encounter but I have still posted them here in case you face any of those… Known Issues, Resolutions and Work-Arounds for VS 10 Web 1-Click Publish…

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