Web Deploy: IIS6 to IIS7 Migrations + Link Extensions

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Hope this helps,

Vishal

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

throw new System.DumbDevException(“Vishal”);

Funny enough but I am here to confess that I did not realize that I had set “Comments Auto-Approve” to off on my blog since I don’t know when…  And as I use Windows Live Writer to write my blogs I never care to go to the blog dashboard for nearly anything…

Anyways, for whatever reason I thought I will go and check if I was missing out on some new features of blogger so I logged in and realized that I had several hundreds of comments piling up waiting for moderation…

So first of all sorry for the dumbness and secondly I ask you to be patient while I weed through all the comments that are accumulated so far…

I am hoping that over this next week or two I will be able to get through them all but if you need anything urgently then do not hesitate to drop me a line at Vishal.Joshi@Microsoft.com…

Thanks - Vishal

Applying XDT magic to App.Config

For several weeks now people have been asking to be able to use the XML Document Transform (XDT) with App.Config files similar to what is available with Web.Config files in VS 2010…
In all honesty there is no official/supported  implementation of XDT for any other project type than Web Application Projects but the good news is that the basis of Web.Config Transformation resides in Web Publishing Pipeline (WPP) which are set of extensible tasks and targets hooked up to provide a great deployment story for Web Applications…
Today, Ming (our senior dev on Visual Studio) and I decided to get together to give some love to App.Config file too… The below implementation is a crude way of getting XDT working into other project types within VS 2010… In a way, I would say it is a big solution for a smaller problem but the idea here is to get people unblocked and show the kind of things that WPP is capable of doing… 
If by now everything is sounding foreign then please check out the articles:

Web.Config Transformation

VS 2010 Snippets for Web.Config Transformations

Web.Config Transforms (XDTs) for any XML files in your web projects
Goals

• Being able to use XDT syntax for App.Config files similar to what you can use with Web.Debug.Config and Web.Release.Config…
• Being able to use this in an automated fashion in build environments like Team Build…
• Reduce the concept count and make it as simple as possible (without digging deep into optimization & performance)…

Please take a look at Visual Studio extension which allows you to do this without the manual workarounds below:

 http://visualstudiogallery.msdn.microsoft.com/69023d00-a4f9-4a34-a6cd-7e854ba318b5

Step by Step Instructions

The example I am using below should be hopefully super simple that you can follow along without any prep work… All you need is VS 2010 which has “Visual Web Developer” components installed…

Step 1 Create a new Windows Forms Application in VS 2010

Step 2 Add App.Config file to the project…

Add simple test settings to App.Config file as shown below:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <appSettings>
    <add key="author" value="Vishal Joshi"/>    
  </appSettings>
</configuration>

Step 3 Add App.Debug.Config file to the project, I would recommend using the same App.Config file adding mechanism as shown below








Step 4 Modify the content of App.Debug.Config as shown below:

<?xml version="1.0"?>

<!-- For more information on using App.config transformation visit http://go.microsoft.com/fwlink/?LinkId=125889 -->

<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
  <appSettings>
    <add key="article" value="XDT Magic for App.Config Files" xdt:Transform="Insert"/>
  </appSettings>
</configuration>

The key things to note above are:

• There is a XDT namespace declaration which allows XDT engine to recognize the Transform/Locator syntax in the file



• There is a new node being inserted into the config file using the syntax xdt:Transform=”Insert”

Step 5 Save the edited files and unload the project frin VS 2010 Solution Explorer using the right click command as shown below:








Step 6 Edit the .csproj/.vbproj file to make App.Debug.Config file to be dependent on App.Config file as shown in the syntax below:

    <Content Include="App.config" />
    <Content Include="App.Debug.Config" >
      <DependentUpon>App.Config</DependentUpon>
    </Content>

The key things to note above are:

• By default the build action of App.Config and App.Debug.Config file will be “ None”… It needs to be changed to “Content”… This is a tiny pre-requisite for WPP but if you encounter any issues because of this then we can dig the work around…



• DependentUpon node will make your App.Debug.Config appear as a node under your App.Config file similar to the way Web.Debug.Config and Web.Release.Config files appear under Web.Config file…



• In VB Projects nested files are hidden so you might need to unhide these by clicking the icon on the solution explorer…

Step 7 Change the ProjectConfigFileName property within your .csproj/.vbproj file



WPP has an inbuilt property called ProjectConfigFileName which is by default set to Web.Config, we need to change this to app.Config which will allow projects like WinForm project not expect web.config files to transform… You can add this property right under ProjectGuid property as shown below:

  <PropertyGroup>
    <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
    <Platform Condition=" '$(Platform)' == '' ">x86</Platform>
    <ProductVersion>8.0.30703</ProductVersion>
    <SchemaVersion>2.0</SchemaVersion>
    <ProjectGuid>{2D587604-866B-4675-8587-FA9728EC59D8}</ProjectGuid>
    <ProjectConfigFileName>App.Config</ProjectConfigFileName>

Step 8 Hook up WPP within your WinForms project by importing the WPP targets.



You can search for “Import” node in your project file and then simply copy below one line for WPP targets import

  <Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets" />

Step 9 Add a target to copy the transformed App.Config file to your output (BIN) directory




You can simply copy paste the below code just before your </project> node closes in the .csproj/.vbproj file

  <Target Name="PostTransformAppConfig" AfterTargets="TransformWebConfig">
    <Copy Condition="Exists('$(TransformWebConfigIntermediateLocation)\transformed\App.config')" 
          SourceFiles="$(TransformWebConfigIntermediateLocation)\transformed\App.config" 
          DestinationFiles="$(OutputPath)\WinFormConfigTransform.exe.config" />
    <Copy Condition="Exists('$(TransformWebConfigIntermediateLocation)\transformed\App.config')" 
          SourceFiles="$(TransformWebConfigIntermediateLocation)\transformed\App.config" 
          DestinationFiles="$(OutputPath)\WinFormConfigTransform.vshost.exe.config" />
  </Target>

The key things to note above are:

• We hooked up the new PostTransformAppConfig target after TransformWebConfig target… The TransformWebConfig target is the native target in WPP which does any XML transform and will do the actual job of transforming App.Config as well..



• The location at which the new App.Config file is getting copied is pretty self explanatory but do note that you do want to change “WinFormConfigTransform” to be the name of your own Project…  I just used a project called “WinFormConfigTransform” and hence the DestinationFiles path is named as such…

Step 10 Run /T:TransformWebConfig task on your Project from MSBuild



You need to use Visual Studio 2010 Command prompt and type in the below command



msbuild C:\Vishal\WinFormConfigTransform.csproj /t:TransformWebConfig



After running the above command if you now check the BIN folder of your project you should see that the Project.exe.Config file is now modified as shown below:



 



NOTE: If you want the App.Config file to be Transformed after every build in your Visual Studio IDE (this will take some perf away but may not even be noticeable) then you can change Step 9 code to be as below:

<Target Name="PostTransformAppConfig" AfterTargets="Build">
    <CallTarget Targets="TransformWebConfig"/>
    <Copy Condition="Exists('$(TransformWebConfigIntermediateLocation)\transformed\App.config')" 
          SourceFiles="$(TransformWebConfigIntermediateLocation)\transformed\App.config" 
          DestinationFiles="$(OutputPath)\WinFormConfigTransform.exe.config" />
    <Copy Condition="Exists('$(TransformWebConfigIntermediateLocation)\transformed\App.config')" 
          SourceFiles="$(TransformWebConfigIntermediateLocation)\transformed\App.config" 
          DestinationFiles="$(OutputPath)\WinFormConfigTransform.vshost.exe.config" />
  </Target>

The only key difference above is that I made the new target to be called after “Build” and in the new target I made a call to “TransformWebConfig” target to ensure the transform happens before we try to copy the transformed app.config file to their final location…




With the above change now when you build in IDE then the new transformed App.Config will be copied to your output directory…



With the above 10 steps you should now be able to Transform your App.config just like the way you do Web.Config files in VS 2010



-Vishal



PS:  Whenever you make changes to your project file (like above) you make your project susceptible to data loss during upgrade to future versions of VS as next versions of VS will not know all the fancy code you put in the files, but such risks are part of the game to get all the fancy toys working :-)

Xml Document Transforms (XDT) for any XML file in your project

There have been several requests floating around to be able to use XDTs (the technology behind Web.Debug.Config/Web.Release.Config) with other XML files within the project…  To make that feasible I wrote a XmlDocumentTransform.targets  file which can generically transform any XML file using the standard Web.Config Transformation syntax introduced with VS 2010…

Learn more about XDT & Web.Config Transformation here…

Now to get started first download XmlDocumentTransform.targets file from my Skydive…

Follow the below simple steps to get transformation working for any well formed XML file in your project…

• Step 1: Save the downloaded XmlDocumentTransform.targets to %ProgramFiles%\MSBuild\Microsoft\VisualStudio\v10.0\Web\XmlDocumentTransform.targets

NOTE: I would highly encourage you to make a copy of the Microsoft.WebApplication.targets file as backup before you do Step 2 below, as if this file is modified incorrectly then your VS 2010 instances might start showing funny problems which will be virtually impossible to debug and the only option left with you will be to repair/uninstall-install VS 2010… (i.e. proceed at your own risk :-))

•  Step 2: Put following line of code in Microsoft.WebApplication.targets file just before closing of the Project node i.e. before </Project>...  
  <Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v10.0\Web\XmlDocumentTransform.targets" Condition="Exists('$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v10.0\Web\XmlDocumentTransform.targets')" />
  The Microsoft.WebApplication.targets file is located at %ProgramFiles%\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications... 

  
NOTE: Changing the above targets file will allow you to use this functionality with all the Web Application Projects (WAPs), if you just want to change this for the current project then you can put the same Import node in .csproj or .vbproj as well...  If you use per project model then you can also check in this file into source code control and have your team use it seamlessly…

• Step 3: Open your .csproj/vbproj file and insert the below property in <PropertyGroup> section  <AllXmlsToTransform>Settings.xml;app.config</AllXmlsToTransform>

 NOTE: The Settings.xml or app.config can be replaced with the name of Xml files you want to transform…

• Step 4: Insert <OnAfterTransformWebConfig>TransformXml;</OnAfterTransformWebConfig> similar to #3 above but do not modify the TransformXml; text here…  This is the actual hook which ties in your project to this generic XDT system...  After making the Step 3 & Step 4 changes your project file should have below content…

• Step 5: Create Setting.Debug.Xml or similar files and put XDT syntax in them... You need to make sure in the .csproj/.vbproj file of yours you have the DependentUpon property is set like the example below:
      <Content Include="Configuration\Settings.xml" />
      <Content Include="Configuration\Settings.Debug.xml">
        <DependentUpon>Configuration\Settings.xml</DependentUpon>
      </Content>
      <Content Include="Configuration\Settings.Release.xml">
        <DependentUpon>Configuration\Settings.xml</DependentUpon>
      </Content>

NOTE: The above will allow your solution to look pretty, i.e. just like web.debug.config and web.release.config files show nested under web.config, your *.$(configuration).* files will show nested under your parent file too…

With the above 5 steps you are all set to use XDT with any of the deployment models covered in the Overview of Web Deployment Post…  In a way above steps harness the power of Web Publishing Pipeline (WPP) extensibility model and you can do several other extensions like above if you are familiar with MsBuild sytax…

SAMPLE:   The remainder of the post is just showing you the steps to test whether the changes you made worked or not (i.e. the remaining half of the post is just playing with what you already accomplished in the first half)… :-)

• To test the above target file I created the below MVC 2.0 project structure:

• Once you put DependentUpon node in your project file you will have to click the  “Show All Files” icon on the solution explorer for VB Projects to see Settings.Debug.Xml
• My Settings.xml file looked as below:

• My Settings.Debug.xml file looked as below:

• To test out I tried simple “file system” publish (Right click on project and say Publish)… The new WAP Publish dialog for me looked as below:

• After publishing my C:\TestPublish folder looked as below:

• Note that Settings.Debug.xml was removed from my final publish location as it is not required for my web to function and the content of Settings.xml file were transformed and looked as below:

TeamBuild/Commandline Approach: You can also use your new transformations from TeamBuild/MsBuild by using the below command (from VS 2010 Command prompt if you are trying locally):

MsBuild MyXDTTestProject.csproj /t:TransformXml

The output of the command line transform should look as below:

As specified above your transformed XML will be stored in obj\$(configuration)\Settings.xml… 

As such feel free to open the XmlDocumentTransform.targets file which you download, I have tried to put as much comments as I could to make it readable…  If you go through it I am sure you will be able to do many other cool things out of it…

-Vishal

Xml Document Transform (XDT) Snippets for VS 2010

During my PDC talk I had shown some of the snippets that can come handy while using Web.Config Transformations…  This post is intended to share the XDT snippets and instructions on how to install them to use them with VS 2010…

• Download XDT zip file from my SkyDrive
• Unzip the files and copy the inner XDT folder into %Program Files%\Microsoft Visual Studio 10.0\Xml\1033\Snippets

• After this the XDT snippets will be available for you to use within any XML file within VS 2010…

To know how to use XDTs for Web.Config file please check out the post about Web.Config Transformations

Few interesting points about Transforms & Locators which are worth noting to do pretty powerful stuff with your XML are:

• Transforms  - Transforms act on a XML node i.e. from XDT engine standpoint the node on which a transform is found is plucked out of the document and passed as a node to the Transform itself (e.g. “SetAttributes” Transform)… The Transform class internally implements the logic of modifying the node with its own special logic (i.e. setting attributes in case of “SetAttributes” Transform) and returns back the node to the engine…  The XDT engine then replaces the new node into the document…  The engine also passes the handle of the parent node to the transform which the transform can then play around with (e.g. “Insert” Transform receives a new node as well as the parent node and has the DOM code of inserting the new node under the parent…)

• Locators – XDT usually traverses through the XML document and constructs the XPath all along e.g. when it hits the add node under connectionStrings in web.config it has already constructed the XPath (/configuration/connectionString/add)…  Locators help with narrowing down the XPath so that the correct node can be picked up… Check out the example below:

   <connectionStrings>
      <add name="1stDB" 
        connectionString="Data Source=Server1;Initial Catalog=DB1;Integrated Security=True" 
           xdt:Transform="SetAttributes" />
      <add name="2ndDB"
           connectionString="Data Source=Server2;Initial Catalog=DB2;Integrated Security=True" 
           xdt:Transform="SetAttributes" xdt:Locator="Match(name)"/>
    </connectionStrings>

Based on the standard logic of XPath traversing XDT will always pick up the first “add” node i.e. one with 1stDB in the example below… That may not be always desirable…  In XDT we could have implemented the logic to do special things for appSettings & connectionStrings but then that would have made XDT specific to web.config instead we implemented Locators which now allows XDT to be general purposes XML transformation engine…  In the above example if we use a Locator called xdt:Locator=”Match(name)” on the 2ndDB then as soon as the XDT engine encouters a locator it calls the class implementing it (i.e. “Match” and allows it to play with the XPath that is being generated… In this case the match locator will help construct the XPath as /configuration/connectionString/add[@name=’2ndDB’]

The high level takeaway here is that when you play around with the snippets for XDT keep the above concepts for Transforms & Locators in mind and with the quick snippet explanations of each transforms and locators you should be able to very easily use all of them… If you encounter any issues plz feel free to reach out…

Thanks!!

-Vishal

Web Deployment Projects Released to Beta (WDP for VS 2010)

 

Our team recently released WDP for VS 2010… The key features to note for WDP for VS 2010 are:

1. All the core features of WDP 2008
2. Migration from WDP 2008 to WDP 201o
3. Multi-Targeting support in WDP 2010
4. Support Web Deploy Packages in the WDP project..

You can read more about the above features on our team blog at Visual Web Developer Team Blog

Download WDP 2010 Beta by clicking here!!

The guidance around using WDP 2010 is

• Use it if you want to migrate to VS 2010 and are currently using WDP for VS 2008
• Use it for TeamBuild/MSBuild based deployment of Web Site Projects in VS 2010…
• Use them for Web Application Projects (WAPs) if you feel it is extremely important for you to pre-compile/merge your projects… If not then you can use Web Deployment features built into VS 2010…

Hope this helps!!

-Vishal

Web Deployment Demos, Slides & Videos for VS 2010 launch

I have been dormant for ever, have been keeping busy on a very exciting project… Anyways April 12th 2010 was a big day with VS 2010 formally launching…  Few days back I asked Twitter whether people needed a ready made talk to talk about VS 2010 Web Deployment as part of the community launch events of VS 2010 and got a lot of asks for the content so here it is… 

Titles & Abstract I would recommend you do not use are below… :-)  The reason I say that is coz VS 2010 & Web Deploy are way more exciting than the way I present here; so get creative and make a fun abstract & title…  The only reason I have them descriptive is so that you know what are the key items to put in there…

Title: Web Deployment with VS 2010 & Web Deploy

Abstract: Web deployment is not as easy as it should be; whether you are deploying to a shared hosting environment or to your company’s web servers there are a lot of manual steps involved.  Check out how new VS 2010 and Web Deploy can help you deploy your web along with its dependencies like databases and IIS settings to any environment with just One Click Publish.  Also check out how  you can transport your entire web in a single .zip file and finally hear all about the web.staging.config, web.release.config etc  and the simple transformation syntax in them to create web.config per deployment configuration… Finally also learn how you can automate your Web Deployments using Team build so you no more have to worry about daily builds and setting up of environments…

Video:  Check out the video at http://microsoftpdc.com/Sessions/FT56, this should prep you up on what are the talking points…

Demos & Slides: You can download it from my SkyDrive

If you have any questions/thoughts on the content you can feel free to write comments here or reach me at @VishalRJoshi 

Hope this helps!!

-Vishal

Web Deployment Painkillers: VS 2010 & MS Deploy

Last week I did a talk at the PDC 2009 and the talk is now available to view online live at

www.microsoftpdc.com/Sessions/FT56

The abstract of the talk was “Learn about next generation of ASP.NET Web Deployment with tips & guidance on how you can reuse and extend the technologies available with VS 2010 to build a hassle free web deployment solution for your team. See how to use VS 2010 and MS Deploy to assist with with creating virtual directories in an automated fashion, setting up app pools correctly, uploading only the changed content, replicating servers in web farms, modifying Web.config files for testing/staging/pre-Prod/UAT/Production environments, setting up team build environment or deploying databases.”

Hope you will enjoy it!!

-Vishal

PS: Btw, the presentation deck is available to download at Web Deployment Painkillers… Feel free to use it the way you like…

VS 2010 Beta 2 Read Me Items for Web Deployment

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

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

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

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

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

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

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

• Web Packaging
• One-Click Publishing
• DB Deployment

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

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

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

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

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

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

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

-Vishal

How to ensure placeholder folders are created during VS 2010 Web Deployment

During many web deployment scenarios developers want to be able create place holder folders where eventually their log files or runtime generated files like XMLs, Images etc will be stored…

With VS 2010 Web Deployment there will be a small work around required for you to be able to deploy place holder folders…  Before I go about explaining the work around let me call out that if you do not know about VS 2010 Web Deployment features it might be worth while to check out the blog series about VS 2010 Web Deployment at Overview Post for VS 2010 Web Deployment…

Anyways, as VS 2010 Web Deployment is completely based on MSBuild based Web Publishing Pipeline (WPP) lot of deployment depends upon the MSBuild constructs…  One of the key features which is also supported using MSBuild based constructs is the ability to exclude Files and Folders from deployment.  I am hoping to write blog posts on both of these topics at some point but currently without going into the details consider following:

There is a file/folder structure like C:\MyWeb\Foo\Bar\myfile.htm…  VS 2010 will allow you to exclude or include myfile.htm or folder “Foo” from Web Deployment… If you now chooses to include myfile.htm but chooses to exclude “Foo” folder then the WPP will get into unwanted complex state for potentially trivial gains…

That is the reason most of the include, exclude, delete etc operations are done at the File level rather than at Folder level… So when you are excluding a folder from deployment  behind the scenes a bunch of files under that folder are getting excluded and the end result is the folder being excluded too… The above explanation is not exactly how it translates into code but is more for understanding purposes…

Anyways, this design decision causes the side effect that if there are no files in a folder then the folder does not get deployed as well… By now I imagine you must have figured out the work around too :-) Ya! just put a place holder file even if it is empty.txt in your place holder folder and it will get deployed too !!

If this causes you a lot of grief then do write back with your scenarios so that we can try to understand and analyze them individually…

Also do note that whether you are creating a web package or doing 1-Click Publish the same rationale applies as ultimately same WPP is executed behind the scenes for both…

-Vishal

How to debug the selected page inside selected project all the time?

As you might already know http://connect.microsoft.com is a way to open bugs/request suggestions on various Microsoft products… One of the repeated suggestion I see for Web Development within Visual Studio is the ability to hit F5 on any .aspx page within a solution and have it be treated as the “Start up page”…

It is pretty common to set a fixed page as a start up page within a Web Project…You could do that simply by right clicking the page of your choice and setting “Set as Start Page” as shown below:

The above will fix your start page to be “Default.aspx” and no matter what you select within the project, Default.aspx will start when you hit F5…

You can make the active selected page as your start up page by going to the Project –> Properties –> Web  and choosing the “Current Page” as your “Start Action”

There is a similar option for Web Site Projects too, although the interesting ask comes up when you have more than one web project in your solution and you want to debug current page from the project you have currently selected…

Most people right click on their project and click “Set as StartUp Project” every time they want to change the project they are debugging  (as shown below):

Although there is a well kept secret in Visual Studio, which is worth noting…  You can actually right click on your “Solution File” and click “Set Start up  projects…”

This will bring up the below dialog:

In this dialog you just need to select the radio button which says “Current Selection” and this will automatically make the project you are in as the start up project…

Effectively by choosing “Current Selection” for the Start Up Project and the “Current Page” for Start Action,  you can now very easily debug the project + web page of your choice simply hitting F5…

-Vishal

 

Technorati Tags: WAP,Web Site,Debugging,F5,Visual Studio,Web Development,ASP.NET

Server specific Web.config sections replacement with WDP

In this post I am hoping to explain how you can change your web.config settings per different server environment using Web Deployment Projects (WDP) for VS 2005 or VS 2008…

First of all let me start with the fact that WDP for VS 2005 as well as WDP for VS 2008 are build configuration aware… In fact, special effort was made in WDP 2005 & WDP 2008 to allow configuration specific settings…

That is the reason when you look at the WDP UI you can see configuration specific dropdowns as shown below:

You can create one build configuration per your server environment eg. “Testing”, “Staging” , “Production” etc and configure all of your WDP settings per build configuration pretty easily… Learn more how to manage configurations per build environment…

Next I want to change connectionStrings section in side the web.config for “Testing” server and “Release” server… The original connection String section in my web.config file looks as below:

<connectionStrings>
    <add name="vishal-db" connectionString="Data Source=vijoshi-DevBox; Initial Catalog=vishal-db; Integrated Security=True"/>
 </connectionStrings>

• For “Testing” environment I would like to change my Data Source to be vijoshi-Testing



• For “Release” environment I would like to change my Data Source to be vijoshi-Release

To accomplish this I am going to add two configuration files to my project named connectionString.Testing.config and connectionString.Release.config… After adding the two files my solution explorer should look as below:

The content of connectionString.Testing.config file will look as below:

<connectionStrings>
  <add name="vishal-db" connectionString="Data Source=vijoshi-Testing; Initial Catalog=vishal-db; Integrated Security=True"/>
</connectionStrings>

Notice that the connectionString.Testing.config only contains connectionStrings section (as opposed to original web.config which may contain many other sections) … Similar to the above example in connectionString.Release.config file I will only change the Data Source to vijoshi-Release…

After these two files are added I can now open my WDP configuration and go to the “Deployment” node and check the “Enable Web.config file replacement”…  After this the only thing I need to do is write connectionStrings=connectionString.Testing.config  as shown below…

 

 

After this when I build my WDP project the connectionStrings section will be replaced by the content of the connectionString.Testing.config…

Also now I can modify the Configuration from “Testing” to “Release” and set the Web.config file section replacements section to look as below

connectionStrings=connectionString.Release.config 

This way you can also modify the other config sections each in a new line of the text box shown above…

Hope this will help…

-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

Do you think building Web sites should be easier, faster and fun?

If you answered “Yes” then it might be interesting to you that there is an opportunity on our team for a person who has passion for making web development easier and exciting for everyone…

[NOTE: I have received a tons of resume already on this posting, thanks to everyone for sending your resume and showing interest… As there are several resumes to look into I will probably try to spend reasonable time over the weekend and respond whether the resume fits the needs of the job or not… Thanks again for your interest…]

This job posting is the unofficial job posting  describing a person whom I am looking to refer to my team to consider for an official job posting which exists somewhere on Microsoft.com… :-)

Our team is chartered with building Web Developer Tools based on web standards and so we are looking for someone who knows HTML, CSS, JavaScript/AJAX…

We would love if this person knows PHP and/or ASP.NET too… If you know someone who loves building Web Sites and is passionate about web development technologies then please pass on the word…

The person will most likely have to relocate to Redmond, WA and would work as a Program Manager (PM) within Microsoft…  Considering that I am inviting folks who are not familiar with Microsoft jargons let me write couple of lines about being a PM… :-)

As a PM, this person will have to be the voice of The Web Developer, an advocate of the web developer to the rest of the team so that the right technologies can be created…

Before I joined Microsoft I use to be some species of a developer i.e. I wrote code almost everyday so being a PM worried me coz it felt like I will not be writing code anymore… Well that is not true, a PM typically needs to represent the customer, in this case the customer is a Web Developer so as a PM, this person should be able to behave like a Web Developer… In short, this person will have the liberty to be amongst the first people to try out new web developer tools & technologies and hence can code as much as he/she likes :-)

Now, many will start asking questions about how many years of experience does one need to have, how much salary will be given, how proficient should one be with Visual Studio and .NET, Is knowing ASP.NET or ASP.NET MVC important; well lot of that will depend upon the person and I do not have finite answers to any of these… !!

But,  at this point I just want to ask simple but important questions to the potential candidate…

• Are you passionate about web development and have a vision of how it can be made much easier, faster and fun…?
• Have you developed real world web sites which are up and running on the internet/intranet…?
• Are you a person who believes in web developer community and contributes towards it in someway, may it be blog, open source code, forums, articles, books, twitter etc
• Do you like speaking in front of a big audience at conferences and talk about the future of web development and doing coolest demos on web development?
• Do you understand what are the gaps in web development today in PHP/ASP.NET and what needs to be done to fix those?

If you answered “Yes” to the questions above send me an email with your resume and some background about the above at FirstName.LastName@Microsoft.com or call me at +1-425-705-2031 and we can talk…

-Vishal

PS: Comments for this blog post have been closed, you can feel free to send me your questions/concerns directly via email…

Raghuraman & Amit – Although my email is already up there at various places but I still changed this based on your recommendation :-)