Web Deploy Parameterization in Action

A few weeks back I explained the key differences between Web.Config Transformation and Web Deploy (aka MSDeploy) Parameterization…  Before you read this post I recommend that you read Transformation vs. Parameterization post, it is tiny and will clear few fundamentals…

Automatic Parameterization

Before I dive in more let me clarify that if you are using VS 2010 then in common scenarios you may not even need to do custom parameterization, coz VS 2010 already parameterizes things like IIS Application Name, Application physical installation directory and connectionStrings… So when you actually create a web deploy .zip package you can easily build it once and deploy it several number of times by changing the parameters values…

Custom Parameterization

The typical scenarios where you will need to do custom parameterization is for scenarios like:

• You have an appSetting  which needs to be changed by server admin at install time…
• You are using a WCF Service and you want to change the end point at install time…
• You have created re-usable web package for community apps and have bunch of questions to ask the users before they install the app (similar to all of the apps that you find in Application Gallery eg ScrewturnWiki, DNN, etc…)

Scenario

In today’s post I am going to use Parameterization with VS 2010 for changing an appSetting & WCF Service end point… Before we do that let us look at the web.config settings which we want to change at install time…

App Settings  - The Log Folder location here (“value” attribute) is something which I want my admin to be able to change at production install time to a shared location so that if my app is virtualized and put on a web farm then I have a common place to go and look at the log…

WCF Endpoint – Below is my WCF EndPoint URL (“address” attribute) which I would like my admin to change to the servers/sites on which the WCF Services will get deployed…

Install Time Experience

Installation of Web Packages can be done in couple of different ways:

• Installation using IIS Manager
• Installation using Command Line

We want to make sure that no matter which direction our IT Admin takes he/she gets an opportunity to provide values for the above two parameters…

Parameters.xml File format

As I explained in the earlier post Parameters.xml file can be passed to Web Deploy when your .zip Web package is being created and that allows Web Deploy to determine what items in your web should it mark as “changeable” at install time…  VS 2010 makes your life easier by allowing you to simply drop the Parameters file in the root of your web project and if a file with the name Parameters.xml is found in the root of your project it passes it to Web Deploy which then parameterizes your web…

The Parameters.xml file follows a specific format, the key attributes to note for each parameter that you declare within parameters.xml file are:

name – Required unique name to identify the parameter with e.g. “Service 1 endpoint address”

description – This text shows up in the UI of IIS Manager to help the user fill in the value so anything clarifying the parameter is cool…

defaultValue - Optionally you can specify a default value for a parameter so that while installing the package a user may know what kind of values are permissible…

scope – Regular Expression to determine what entities (files e.g. web.config, DBs, Web Deploy providers etc) does the parameter apply to

kind – There are several kinds of parameters but the key ones to remember are:

• XmlFile – Use this for web.config, any settings XML files etc where you can make replacements using XPath
• TextFile – Use this for non-XML file where you can make replacements by looking for fixed text or token within a file. e.g. you can put @@replaceme@@ in the a settings.ini file and during installation that text can be replaced

match -  This depends upon the parameter kind… For e.g. for XmlFile parameter the match expression would be a XPath… For TextFile the match expression could be @@replaceme@@ which you might pre-place in the file…

Declaring Parameters using Parameters.xml

Below is the content of Parameters.xml file that I dropped to the root of my MVC Application

<?xml version="1.0" encoding="utf-8" ?>
<parameters >

  <parameter name="Log Folder Location" description="Please provide a shared location where the app can write log files to" defaultValue="\\Logs\MvcApp\Logs\" tags="">
    <parameterEntry kind="XmlFile" scope="\\web.config$" match="/configuration/appSettings/add[@key='LogFolder']/@value" />
  </parameter>

  <parameter name="WCF Service1 Endpoint Address" description="Please provide the Endpoint address for Service1 that this MVC App needs to call" defaultValue="http://localhost:61938/Service1.svc" tags="">
    <parameterEntry kind="XmlFile" scope="\\web.config$" match="//system.serviceModel/client/endpoint/@address" />
  </parameter>
  
 </parameters>

 

If you notice each of the Parameter above you can see that I am using XmlFile parameter kind with Xpath as the match syntax…  After adding this Parameters.xml file into my project my solution explorer looks as below:

Now I can simply right click on my MvcApplication and hit “Build Deployment Package”…  The resultant .zip file should be created at obj\Debug\Package\MvcApplication1.zip…

Validating that Parameters really worked

• Now to validate whether the parameters really worked you can very quickly open IIS Manager (Start –> Run –> InetMgr) and select your Default Web Site



• You can now click the “Import Application” command on the right side bar and pass the newly created .zip package to it.

• On Hitting  next on the Import Application wizard you will be able to see the “Parameterization” screen which user will be able to pass values to the parameters.  Notice even our defaultValues provided in the Parameters.xml show up:

• I am now changing the value of these variables as shown below:

• When I now go ahead and finish the wizard by clicking “Next” and go ahead and inspect the Web.Config file in the deployed location, I can see that the changed parameter values were applied to the web.config file seamlessly…

• Also do note that in the process above “Parameters.xml” will also get deployed with your web application, in reality you do not need that file… To avoid that file from getting deployed you can go to its properties (select the file and hit F4) and set “Build Action” = None as shown below:

 

There is a ton more power of parameters.xml file that you can explore via Technet Article on Web Deploy Parameters or IIS.NET Articles about Parameters.xml but for scenario like ours the above information should hopefully suffice…

Thanks for reading :-)

-Vishal

Parameterization vs. Web.Config Transformation

I was recently asked about being able to change values of different variables like ConnectionStrings, Installation physical directory, app Settings etc during install time rather than build time, so I thought it might be worth while to de-mystify the concepts around Web.Config Transforms and Parameterization…

Web.Config Transformation

Geeks say Web.Config Transformation is a great feature of Web Deploy (aka MsDeploy), well the first part about being a great feature is true :-) but it is important to note that Web.Config Transformation is not a Web Deploy feature but it instead is a VS 2010 only feature.  Web.Config Transformation is connected with Build configuration of MSBuild/VS/Team Build etc…  Its XML transformation engine is wrapped in MSBuild and has a UI around in VS 2010 which yeilds following benefits:

• You get to tie Web.Config Transform with various build configurations and access it independently from Team Build.
• You can use it with any deployment mechanism like File System, FTP, FTPS, or Web Deploy
• You can use it in projects other than Web Projects where you want to transform XML files

If you are building a deployment web package (.zip) and know which environment you are building for then web.config transformation is great.  This is the category where many of us fall coz we build for a release environment and need the right config file to go in that deployment package.  For that matter many people are just fine creating web packages for the correct environment they are deploying to…

Now for others who want to be able to build just once and deploy to both test as well as staging/release environment then an embedded web.config file for one environment may not work.  For this scenario there is parameterization.

Parameterization

Parameterization, unlike Web.Config Transform is Web Deploy (aka MsDeploy) only feature, which means that it will not work in non-Web projects or when you are using other protocols like FTP/FTPS etc.  Parameterization from Web Deploy standpoint is a 2 step process

1. Declare Parameters: You create a Parameters.xml file and pass it to Web Deploy while creating the package…  In this file you need to indicate what file you want to parameterize  (e.g. web.config), what variable inside the file needs to be parameterized (e.g. connectionString) and what would be the default value of the variable (e.g. release connectionString)… Using Parameters.xml file, Web Deploy will create an internal meta data file within your .zip package which guides Web Deploy to know what “Questions” to ask the person who is installing the .zip package… 
2. Set Parameters: When user is about to install the web package the value of the Parameters can be provided to Web Deploy via several means.  In case you are using IIS Manager to install the package then the IIS Manager UI will automatically show the Parameters with filled in default values.  If you are using Web Deploy command line to install the package then you can provide a setParameters.xml file to the commandline (in case of VS 2010 generated deploy.cmd file just having setParameters.xml file in same folder as the .cmd and .zip file is sufficient).  The setParameters.xml file is a very simple name-value pair file in which you can provide the value of the parameter adjacent to its name.

In one of the future posts I will write more about how to use Parameterization for some canonical deployment scenarios, but hopefully this will lay the foundation of how to differentiate between build time transforms from install time parameters.

Conclusion

If you can know your environment settings during build time use Web.Config transformation. 

If you would want to create deployment package only once and then enter the settings during install time then use Parameters.xml

VS 2010 actually uses a combination of Parameters and Web.Config transforms to provide you with a seamless experience (i.e. connectionStrings, IIS Application Name etc are already parameterized by default) so for most common scenarios you would hopefully not have to delve into understanding all the details but if you have any questions then of course feel free to ask here or via email…

Thanks

Vishal

Live Meeting: Simplifying Deployment With the Web Deployment Tool (MSDeploy)

One of our MVPs Sayed Ibrahim Hashimi is doing a Live Meeting  MVP TV talk on : Simplifying Deployment With the Web Deployment Tool (MSDeploy)

You are invited to join the talk which is scheduled for

Wednesday, October 14^th, 2009 | 4:00pm – 5:00pm (PDT, Redmond time)

Abstract

Deploying ASP.NET Websites has always been a challenge and different teams have used different approaches to overcoming those challenges. Microsoft has offered some support for making deployment easier in the past. For instance they first introduced Web Deployment Projects for Visual Studio 2005, and also have a version for 2008. Web Deployment Projects do greatly simplify the process of calling the aspnet_compiler and aspnet_merge tool but even though their title states “Deployment” they had no support for physically deploying the site. Now Microsoft has introduced the Web Deployment Tool, also known as MSDeploy. MSDeploy will bridge the gap between taking a web site and physically deploying it to its destination. With MSDeploy you can easily and very effectively perform tasks such as pushing an ASP.NET site (Web site, Web Application Project, ASP.NET, etc) from one machine to several other machines. This is achieved by the target machines having the MSDeploy Remote Agent Service installed and running. You can sync two different Web Sites that are hosted in IIS, you can create a web package (simply a .zip file) and use that as your source, you can sync two different folders, and many other options. Another compelling feature of MSDeploy is that it will be integrated into Visual Studio 2010. From Visual Studio 2010 you can compile your ASP.NET Web Application Project and then create the Web Package which contains all your content files plus IIS settings. This one file will full describe your web.

Live Meeting Information

Join the meeting.
Audio Information
Computer Audio
To use computer audio, you need speakers and microphone, or a headset.
Telephone conferencing
Use the information below to connect:
Toll-free: +1 (866) 500-6738
Toll: +1 (203) 480-8000
Participant code: 5460396

Please join 10 minutes prior to the start time.

First Time Users:
To save time before the meeting, check your system to make sure it is ready to use Microsoft Office Live Meeting.
Notes

Troubleshooting
Unable to join the meeting? Follow these steps:

1. Copy this address and paste it into your web browser:
https://www.livemeeting.com/cc/mvp/join

2. Copy and paste the required information:
Meeting ID: PR7D6Z
Entry Code: A5128ML0Y0D
Location: https://www.livemeeting.com/cc/mvp

If you still cannot enter the meeting, contact support

Note

Microsoft Office Live Meeting can be used to record meetings. By participating in this meeting, you agree that your communications may be monitored or recorded at any time during the meeting.

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…

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

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