Web Deployment: Web.Config Transformation

We have earlier discussed about Web Deployment and Web Packaging quite a bit, today I wanted to dive into web.config transformation. If you would like to check out the other topics please read through the earlier blog posts below:

• 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

Usually web applications go through a chain of server deployments before being finally being deployed to production environment. Some of these environments can be Developer box (Debug), QA Server, Staging/Pre-Production, Production (Release). While transitioning between these environments various settings of the web application residing in web.config file change, some of these settings can be items like application settings, connection strings, debug flags, web services end points etc.

VS10’s new web.config transformation model allows you to modify your web.config file in an automated fashion during deployment of your applications to various server environments. To help command line based deployments, Web.Config transformation is implemented as an MSBuild task behind the scene hence you can simply call it even outside of deployment realm.

I will try to go through below steps to explain web.config transformation in detail

1. Creating a “Staging” Configuration on your developer box

2. Adding a “Staging” Web.Config Transform file to your project

3. Writing simple transforms to change developer box connection string settings into “Staging” environment settings

4. Generating a new transformed web.config file for “Staging” environment from command line

5. Generating a new transformed web.config file for “Staging” environment from VS UI

6. Understanding various available web.config Transforms and Locators

7. Using Web.config transformation toolset for config files in sub-folders within the project

Step 1: Creating a “Staging” Configuration on your developer box

Debug and Release build configurations are available by default within Visual Studio but if you would like to add more build configurations (for various server environments like “Dev”, “QA”, “Staging”, “Production” etc then you can do so by going to the Project menu Build --> Configuration Manager… Learn more about creating build configurations.

Step 2: Adding a “Staging” Web.Config Transform file to your project

One of the goals while designing web.config transformation was to make sure that the original runtime web.config file does not need to be modified to ensure that there would be no performance impacts and also to make sure that the design time syntax is not mixed with runtime syntax. To support this goal the concept of Configuration specific web.config files was introduced.

These web.config files follow a naming convention of web.configuration.config. For example the web.config files for various Visual Studio + Custom configurations will look as below:

Any new Web Application Project (WAP) created in VS10 will by default have Web.Debug.Config and Web.Release.config files added to the project. If you add new configurations (e.g. “Staging”) or if you upgrade pre-VS10 projects to VS10 then you will have to issue a command to VS to generate the Configuration specific Transform files as needed.

To add configuration specific transform file (e.g. Web.Staging.Config) you can right click the original web.config file and click the context menu command “Add Config Transforms” as shown below:

On clicking the “Add Config Transform” command VS10 will detect the configurations that do not have a transform associated with them and will automatically create the missing transform files. It will not overwrite an existing transform file. If you do not want a particular configuration transform file then you can feel free to delete it off.

Note: In case of VB Web Application Projects the web.configuration.config transform files will not be visible till you enable the hidden file views as shown below:

The transform files are design time files only and will not be deployed or packaged by VS10. If you are going to xCopy deploy your web application it is advised that you should explicitly leave out these files from deployment just like you do with project (.csproj/.vbproj) or user (.user) files…

Note: These transform files should not be harmful even if deployed as runtime does not use them in any fashion and additionally ASP.NET makes sure that .config files are not browsable in any way.

Step 3: Writing simple transforms to change developer box connection string settings into “Staging” environment settings

Web.Config Transformation Engine is a simple XML Transformation Engine which takes a source file (your project’s original web.config file) and a transform file (e.g. web.staging.config) and produces an output file (web.config ready for staging environment).

The Transform file (e.g. web.staging.config ) needs to have XML Document Transform namespace registered at the root node as shown below:

<?xml version="1.0"?>
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
</configuration>

Note: The transform web.config file needs to be a well formed XML.

Inside the XML-Document-Transform namespace two new attributes are defined. These attributes are important to understand as they drive the XML Transformation Engine.

Transform – This attribute inside the Web.Staging.config informs the Transformation engine the way to modify web.config file for specific configuration (i.e. staging). Some examples of what Transforms can do are:

• Replacing a node

• Inserting a node

• Delete a node

• Removing Attributes

• Setting Attributes

Locator – This attribute inside the web.staging.config helps the Transformation engine to exactly pin-point the web.config node that the transform from web.staging.config should be applied to. Some examples of what Locators can do are:

• Match on value of a node’s attribute

• Exact XPath of where to find a node

• A condition match to find a node

Based on the above basic understanding let us try to transform connection string from original web.config file to match Staging environment’s connection string

Let us examine the original web.config file and identify the items to replace... Original Web Config file’s connection string section looks as below:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
  <connectionStrings>
    <add name="personalDB"
     connectionString="Server=DevBox; Database=personal; User Id=admin; password=P@ssw0rd" providerName="System.Data.SqlClient" />
    <add name="professionalDB"
     connectionString="Server=DevBox; Database=professional; User Id=admin; password=P@ssw0rd" providerName="System.Data.SqlClient" />
</connectionStrings>
....
....
</configuration>

NOTE: It is not advisable to keep connection string unencrypted in the web.config file, my example is just for demonstration purposes.

Let us assume that we would like to make following changes to web.config file when moving to staging environment

• For “personalDB” we would like to change the connectionString to reflect Server=StagingBox, UserId=admin, passoword=StagingPersonalPassword”

• For “professionalDB” we would like to change the connectionString to reflect Server=StagingBox, UserId=professional, passoword=StagingProfessionalPassword”

To make the above change happen we will have to open web.Staging.Config file and write the below piece of code

<?xml version="1.0"?>
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
     <connectionStrings>
        <add name="personalDB"
          connectionString="Server=StagingBox; Database=personal; User   

          Id=admin; password=StagingPersonalPassword"
          providerName="System.Data.SqlClient" xdt:Transform="Replace"    

          xdt:Locator="Match(name)" />
        <add name="professionalDB"
         connectionString="Server=StagingBox; Database=professional; User  

         Id=professional; password=StagingProfessionalPassword"
         providerName="System.Data.SqlClient" xdt:Transform="Replace"

         xdt:Locator="Match(name)"/>
       </connectionStrings>
</configuration>

The above syntax in web.staging.config has Transform and Locator attributes from the xdt namespace. If we analyze the connection string node syntax we can notice that the Transform used here is “Replace” which is instructing the Transformation Engine to Replace the entire node

Further if we notice the Locator used here is “Match” which is informing Transformation engine that among all the “configuration/connectionStrings/add” nodes that are found, pick up the node whose name attribute matches with the name attribute of <add> node in web.Staging.config.

Also if you notice web.Staging.config does not contain anything else but the connectionStrings section (i.e. it does not have <system.web> and various other sections that web.config file usually has, this is because of the fact that the Transformation Engine does not require a complete web.config file in web.staging.config. It does the merging for you thus saving you duplication of all the rest of the sections in web.config file.

Simplest Approach: If you do not mind replicating the entire web.config file in web.staging.config then you can certainly do so by copying the entire web.config content into web.staging.config and change the relevant nodes inside web.staging.config. In such a situation you will just have to put xdt:Transform="Replace" attribute on the topmost node (i.e. configuration) of web.staging.config. You will not need xdt:Locator attribute at all as you are replacing your entire web.config file with web.staging.config without Matching anything.

So far we have seen one Transform (i.e. Replace) and one Locator (i.e. Match), we will see various other Transforms and Locators further in the post but first let us understand how we can produce the Transformed web.config file for the Staging environment after using original web.config and web.staging.config.

Step 4: Generating a new transformed web.config file for “Staging” environment from command line

Open Visual Studio Command prompt by going to Start --> Program Files –> Visual Studio v10.0 –> Visual Studio tools –> Visual Studio 10.0 Command Prompt

Type “MSBuild “Path to Application project file (.csproj/.vbproj) ” /t:TransformWebConfig /p:Configuration=Staging" and hit enter as shown below:

Once the transformation is successful the web.config for the “Staging” configuration will be stored under obj -->Staging folder under your project root (In solution explorer you can access this folder by first un-hiding the hidden files) :

• In the solution explorer click the button to show hidden files
• Open the Obj folder

• Navigate to your Active configuration (in our current case it is “Staging”)

• You can find the transformed web.config there

You can now verify that the new staging web.config file generated has the changed connection string section.

Step 5: Generating a new transformed web.config file for “Staging” environment from VS UI

Right Click on your project and click Package –> Create Package

The Create Package step already does web.config transformation as one of its intermediate steps before creating a package and hence you should be able to find the transformed web.config file in the same place as described in Step 4

Step 6: Understanding various available web.config Transforms and Locators

xdt:Locators

The inbuilt xdt:Locators are discussed below.

• Match - In the provided syntax sample below the Replace transform will occur only when the name Northwind matches in the list of connection strings in the source web.config.Do note that Match Locator can take multiple attributeNames as parameters e.g. Match(name, providerName) ]

<connectionStrings>
     <add name="Northwind" connectionString="connectionString goes    here" providerName="System.Data.SqlClient" xdt:Transform="Replace"          xdt:Locator="Match(name)" />
</connectionStrings>

·         Condition - Condition Locator will create an XPath predicate which will be appended to current element’s XPath. The resultant XPath generated in the below example is “/configuration/connectionStrings/add[@name='Northwind or @providerName=’ System.Data.SqlClient’ ]”

This XPath is then used to search for the correct node in the source web.config file

<connectionStrings>
      <add name="Northwind" connectionString="connectionString goes here"

        providerName="System.Data.SqlClient" xdt:Transform="Replace"

        xdt:Locator="Condition(@name=’Northwind or @providerName=’

        System.Data.SqlClient’)" />
</connectionStrings>

·         XPath- This Locator will support complicated XPath expressions to identify the source web.config nodes. In the syntax example we can see that the XPath provided will allow user to replace system.web section no matter where it is located inside the web.config (i.e. all the system.web sections under any location tag will be removed.)

<location path="c:\MySite\Admin" >
    <system.web xdt:Transform="RemoveAll" xdt:Locator="XPath(//system.web)">
    ...
    </system.web>
</location>

xdt:Transform

• Replace - Completely replaces the first matching element along with all of its children from the destination web.config (e.g. staging environment’s web.config file). Do note that transforms do not modify your source web.config file.
  <assemblies xdt:Transform="Replace">
      <add assembly="System.Core, Version=3.5.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089" />
  </assemblies>

·         Remove - Removes the first matching element along with all of its children
<assemblies xdt:Transform="Remove"></assemblies>

·         RemoveAll - Removes all the matching elements from the destination’s web.config (e.g. staging environment’s web.config file).

<connectionStrings>
    <add xdt:Transform="RemoveAll"/>
</connectionStrings>

·         Insert - Inserts the element defined in web.staging.config at the bottom of the list of all the siblings in the destination web.config (e.g. staging environment’s web.config file).

<authorization>
     <deny users="*" xdt:Transform="Insert"/>
</authorization>

·         SetAttributes - Takes the value of the specified attributes from the web.staging.config and sets the attributes of the matching element in the destination web.config. This Transform takes a comma separated list of attributes which need to be set. If no attributes are given to SetAttributes transform then it assumes that you would like to Set all the attributes present on the corresponding node in web.staging.config
<compilation batch="false"

xdt:Transform="SetAttributes(batch)">

</compilation>

·         RemoveAttributes - Removes the specified attributes from the destination web.config (i.e. staging environment’s web.config file). The syntax example shows how multiple attributes can be removed.

<compilation
xdt:Transform="RemoveAttributes(debug,batch)">
</compilation>

• InsertAfter (XPath) - Inserts the element defined in the web.staging.config exactly after the element defined by the specified XPath passed to “InsertAfter()” transform. In the syntax example the element <deny users="Vishal" />will be exactly inserted after the element <allow roles="Admins" /> in the destinationXML.

<authorization>
     <deny users="Vishal" xdt:Transform="InsertAfter(/configuration/system.web/authorization/allow[@roles='Admins'])” />

</authorization>

• InsertBefore (XPath) - Inserts the element defined in the web.staging.config exactly before the element defined by the specified XPath passed to “InsertBefore()” transform. In the syntax example the element <allow roles="Admins" />will be exactly inserted before the element <deny users="*" />in the destinationXML.

<authorization>
      <allow roles=" Admins" xdt:Transform="InsertBefore(/configuration/system.web/authorization/ deny[@users='*'])" />
</authorization>

Some advanced points to note:

• If the Transformation Engine does not find a xdt:Transform attribute specified on a node in web.staging.config file then that node is ignored for Transformation and the Tranformation engine moves ahead traversing the rest of the web.staging.config.

• A xdt:Transform attribute on a parent can very easily impact child elements eve if there is no Transform specified for child e.g. If xdt:Transform=”Replace” is put on <system.web> then everything underneath <system.web> node will be replaced with the content from web.staging.config

• It is completely valid to place xdt:Locators attributes on arbitrary nodes inside web.staging.config just for filtering purposes. xdt:Locator does not need to be accompanied with xdt:Transform attribute. (great example here is <location> tag which might just be used for filtering… The example code here would be:

<location path="c:\MySite\Admin" xdt:Locator="Match(path)">>
        <system.web>
          ... Bunch of transforms written under here will
          .... only apply if location path = C:\MySite\Admin
        </system.web>
</location>

Step 7: Using Web.config transformation toolset for config files in sub-folders within the project

All of the above discussion directly applies to any web.config file present in sub folders of your project (e.g. if you have a separate web.config file for say “Admin” folder then VS 10 will support transforms for them too). You can add transform files within sub-folders and use the same packaging functionality mentioned in all of the above steps to create transformed web.config files for web.config files specific to the sub folders within your project.

I think this has become a rather long post; but I hope it helps!!

Technorati Tags: VS10,Visual Studio 2010,Web Deployment,Web.Config Transformation,WAP,Web.Config

Web Packaging: Installing Web Packages using Command Line

 

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

Web Deployment with VS 2010 and IIS

Web Packaging: Creating a Web Package using VS 2010

Web Packaging: Creating web packages using MSBuild

How does Web Deployment with VS 10 & MSDeploy Work? 

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

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

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

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

 

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

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

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

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

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

So on your dev box below is what happens:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

How does Web Deployment with VS 10 & MSDeploy Work?

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

Web Deployment with VS 2010 and IIS

Web Packaging: Creating a Web Package using VS 2010

Web Packaging: Creating web packages using MSBuild

 

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

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

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

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

Source

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

Destination

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

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

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

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

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

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

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

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

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

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

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

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

When you are ready to deploy then on the destination you can feed the web package and the destination manifest to MSDeploy to deploy your web site.  In the destination manifest you can change the values like “IIS Application Name”, “DB connection strings” etc This is how you can use web packages on any machine with MSDeploy and by configuring your deployment options in the destination manifest you can go and and easily recreate your webs.

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

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

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

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

 

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

Web Packaging: Creating web packages using MSBuild

 

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

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

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

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

• MSBuild
• NAnt
• NMake

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

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

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

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

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

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

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

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

MSBuild “YourProject.csproj”

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

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

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

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

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

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

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

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

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

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

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

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

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

Web Packaging: Creating a Web Package using VS 2010

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

• Web Deployment with VS 2010 and IIS

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

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

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

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

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

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

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

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

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

Step 2: Configure IIS Settings in IIS Manager

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

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

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

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

Step 3: Configure Package Settings

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

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

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

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

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

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

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

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

Package Items

 

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

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

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

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

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

Package Settings

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

Step 4: Create the "Web Package"

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

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

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

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

 

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

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

 

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

Hope this helps...

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

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

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

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

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

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

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

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

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

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

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

Hope this helps...

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

Tips & Tricks: Deploying Generated Debug Symbols for your Web

Many developers always generate debug symbols so that they can be used to debug even the production environment if need be and to a great extent this can be considered as a best practice, but that does not mean that organizations deploy their Debug Symbols.

If you would like to generate debug symbols for your application you can do so by going to the “Build” tab in the Property Pages and clicking “Advanced” bottom at the bottom. Here you will have different options for the level of debug symbols you would like to generate for your Web Application Projects (WAP)

C#

VB

Generation of Debug symbols can be configured per "Build Configuration"...  To learn more about managing build configurations click here

Hope this helps...

Technorati Tags: Debugging,VS,Visual Studio 2010,VS 2008,VS10,Deployment,PDB,Debug Symbols

Tips & Tricks: Managing environment specific properties by using Configuration Manager

Many property pages of a project (File --> New --> Project --> Web Application Project) support Configuration  specific properties:

What this essentially means is that all the properties in that tab can be saved in the project file and will be saved per configuration.  This would mean that when your active configuration is "Debug" then all the "Debug" settings will be used.

Debug and Release configurations are available by default inVisual Studio but if you would like to add more build configurations (for various server environments like “Dev”, “QA”, “Staging”, “Production” etc then you can do so by going to the Build --> Configuration Manager.

You can also select your active configuration for Visual Studio 10 from the Configuration Manager UI as shown above.

The configurations are stored in the project file as shown below:

Note: Deleting a configuration for the solution does not delete it for every project within the solution and visa versa, so when using Configuration Manager make sure that you remove the configurations from the correct locations

Hope this helps...

Technorati Tags: Configuration,Visual Studio 2010,VS,VS 2010,Configuration Manager,Debug,Release,Staging,Build

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

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

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

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

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

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

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

Hope this helps...

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

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

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

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

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

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

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

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

Hope this helps...

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

Web Deployment with VS 2010 and IIS

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

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

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

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

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

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

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

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

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

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

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

· SQL Server DB

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

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

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

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

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

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

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

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

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

VS 2010 for Web Developer Previews

 

At PDC 2008 in LA and TechEd EMEA 2008 in Barcelona we announced key new features for Visual Studio 2010 for Web Developers...  Apart from our focus on MVC, Dynamic Data, Silverlight and other key ASP.NET runtime functionality, this was the first time we announced the key investments pillars for Web Developers in VS 2010...  Over the next year or so we will be writing in details about these new features, but to start off  I thought it would be great to share various videos which are available to view online today ...

Visual Studio 2010 - Web Development Overview

In this talk we provided the glimpse of the major investment areas in VS 2010.  The talk is divided into following key areas

• Design View - Improved CSS 2.1 Support &  standards compliance
• Source View
• HTML Snippets
• JScript Intellisense
• Web Deployment
• Web.Config Transformation
• Web 1-Click Publish

Jeff did a great presentation at PDC on this topic which can be viewed at the link below:

http://channel9.msdn.com/pdc2008/TL48/ (77.32 mins)

I also presented a similar talk at TechEd EMEA which is available for viewing below:

Web Development Futures with Visual Studio 2010 from Vishal Joshi on Vimeo.

http://www.vimeo.com/2667207 (62.42 mins)

Visual Studio 2010 - Web Deployment

In this talk we talk about Web Deployment in detail and how next wave of Web Deployment technologies will make deployment a much easier task.  The key focus areas of this talk are:

• Web Packaging - Packaging your web applications into .zip files
• Web.Config Transformation - Transforming your web.config file (i.e. connection string, debug flags etc) from dev environment to production environment
• DB Deployment - Packaging and deploying your SQL Server databases along with your web application
• Web Publishing - Using Web 1-Click Publish functionality to deploy your web application with ease.

I did a presentation on web deployment at PDC and TechEd EMEA; the PDC presentation can be viewed at the below link:

http://channel9.msdn.com/pdc2008/PC33/  (84.42 mins)

If you would like to see a more compressed version of the talk then I also did a talk with Jason Olson in Visual Studio 2010 and the .NET Framework 4.0 Week! you can view this video at the below link:

http://channel9.msdn.com/posts/VisualStudio/Web-Development-and-Deployment-with-Visual-Studio-2010/ (34.40 mins)

Hope you will enjoy these videos...

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

KritZu: Zune playlist generator based on folder structure

 

Some time back we got Zune and uploaded our thousands of songs on to it... 

One of the things that we had earlier done was arranging all the songs based on playlists on our computer hard disk in folder structure; things like "Classic Rock", "Heavy Metal", "Jazz", "Ghazals", etc... Many a times we also had multiple level of folder hierarchy set up like My Music --> English --> Rock --> Classic Rock OR Hindi --> Ghazals --> Movie Ghazals and so on...

Anyway's we painfully learnt that Zune's software runs out of meta-data; although it allows me to sort songs based on genres, album, artist etc it does not create playlists based on the directory structure on my computer hard disk...  Well we initially started off doing this manually but soon realized that this will take days for us to complete...  So I wrote this quick utility which will create Zune playlists based on the folder structure on the hard disk...

Following are the easy steps to use it:

1. Download KritZu from https://cid-c4e57bdd18ff6eaa.skydrive.live.com/browse.aspx/Public
2. Unzip KritZu.Exe at the location you want...
3. Launch KritZu... 

Few points to note:

• KritZu will pick up .mp3, .wma, .m4v, .mp4, .m4a, .m4b and .mov files inside the playlists...
• To find out the location where Zune playlists should be placed (i.e. second textbox on KritZu) follow below steps:
  • Open Zune software, on top right you should find settings options:
  • Go to the Zune Folder section as shown below and note the location of Zune folder
  • Notice that the Audio location in the above example is C:\Users\user\Music\Zune... In this situation the playlist location for audio will be C:\Users\user\Music\Zune\Playlists
  • If the Playlists folder does not exist then feel free to create it or else KritZu will create it for you...  Now the output of KritZu will automatically be picked up by Zune next time you connect to your machine.

Hope this will help...

-Vishal

PS: Do make sure that you have atleast one media file in the root folder coz KritZu is little silly, it gets confused if no media file is present in the root folder :-)