10-4 Episode 10: Making Web Deployment Easier

Discussione

• 

  If you would like to dive in further detail you can also check out article series that we have started at below location:
  
  http://vishaljoshi.blogspot.com/2009/02/web-packaging-creating-web-packages.html
  
  Also do check out how to deploy your databases along with your web at deployment videos at below link:
  
  http://vishaljoshi.blogspot.com/2008/12/vs-2010-for-web-developer-previews.html
  
  -Vishal
  

• 

  Thank you
  
  Looks nice.
  
  Can we set in the config transformation or in another place an option e.g.  to not deploy some folder or even specify files which not to deploy. I have got quite often some work/test directories which I am happy to have on my test web server but when deploying I don't want to deploy them..don't you guys have got similar experiences sometimes?
  
  Thanks and well done.
  
  Vaso.

• 

  Hi Vaso,
  
  You can accomplish this with custom MSDeploy manifests, but not with the current Visual Studio integration. In fact there is a ton of automation that you can do with MSDeploy - its a great tool and I'm really happy to see it integrating into VS.
  
  Drew

• 

  How does the web.config transformation work in situations with multiple environments and with multiple servers in each environment, and possibly multiple environments of the same level of deployment (e.g. two testing vs. one production environment). 
  
  Specifically, is it possible to have a 'hierarchical' transformation, whereas there may be both a testing and production environment with one web.config that would apply to all of your sites.  Then, in the production environment there might be multiple servers that each have a transformation file for the unique settings required for those servers in production.  However in the testing environment there would not only be multiple unique servers in the testing environment, but multiple testing environments (say T1 and T2).  So each server's web.config would be acted on three times, the global web config would be modified by the testing environment transformation, again by the track level transformation, and finally one for the specific server. 
  
  Such a creature would be like finding a goose that lays golden eggs.  Except, in this case, it would be golden web.configs.
  

• 

  forget web deployment, whats up with that snazzy IDE ?!?  When can we get our hands on the yumminess

• 

  Will these changes also be available for the App.config file in non web apps?
  
  I like the new WFP based Visual Studio by the way, but hate the change from +/- to the dreaded Vista style arrows

• 

  I've seen way too many "roll your own" approaches to the environment-specific configs problem, so I like that there's finally an integrated solution!
  
  Now...I'm not sold on using build configuration to drive this process.  If I add a new "Staging" configuration, don't I now have the problem of keeping that in sync with the "Release" configuration?

• 

  Why did you invent a new syntax for config transformations instead of using XSLT?

• 

  They mentioned this at pdc i think.  It was something to do with the syntax being more similar to the web.config which i have to agree with since xslt can be quite messy.

• 

  Keep in mind that there are quite a few capabilities in IIS7 to help with this as well. IIS7 has a shared configuration capability that allows you to share configuration across a web farm, including local overrides for specific server settings. You can push your application settings up to the shared config file and take advantage of that feature.
  
  You can also customize your MSDeploy manifests to transform settings outside of what Visual Studio is doing.

• 

  Unfortunately, this is for web.config only.

• 

  I don't think I follow. The settings in the transformation are specific to the target environment, so you wouldn't need to keep them in sync between staging and production.

• 

  Really helpful feature. Thanks for adding this in.
  
  I was wondering if the onclick deployment feature can be extended with custom steps to meet policy requirements in an Enterprise. For example I cannot do a direct deploy to CONS/DAY1/PROD my self from my box, I cannot even connect to it. If it is possible for me to publish the PROD builds to a local directory then run some custom step which can zip it, check it into a predefined VSS, label it and send a notfication to environment engineers that would be super cool ... may be its too much to ask for, but just my wishlist!

• 

  Will it be possible to access the publish features via MSBuild directly? It would be great if they could be utilised by the TFS Build Server for CI

• 

  Vaso,
       Using Visual Studio 2010 you will be able to exclude test files and folders from deployment...  I am hoping to write a blog post on this soon...  In the meantime if you want to follow more details on how MSDeploy integration works with VS 10 you can read the below blog post series... http://vishaljoshi.blogspot.com/2009/03/web-packaging-installing-web-packages.html
  -Vishal

• 

  Slace,
  Yes MSDeploy Publish feature will be accessible via MSBuild as well so setting up CI with it will be possibly...
  -Vishal

• 

  Shreedhar,
      In a way what you want will be possible with Web Packaging, there are tiny bit of manual steps involved but them aside it is certainly feasible... You can get a glimpse of what all is possible using MSBuild, commandline and Team Build integration by reading the below blog post about Creation and Deployment of MsDeploy package using Command line
      Eventually I am hoping to write a blog post to accomplish exactly what you are looking for, hope so that I will get to it soon enough...
  -Vishal

• 

  C S S,
          I would like to understand your scenario better and try to make sure that our team tries to address it although currently I am unable to understand it clearly...  Can you please write me an email at vishal.joshi@microsoft.com or call me at +1-425-705-2031 and I will be happy to discuss your scenario in detail... 
  -Vishal

• 

  Daniel,
         Glad to know that you like the new UI... That was our goal as well...  There are tiny yeh!! and nah!! all over the place but trust me the usability team over here spent a tons of time in looking into usability in great detail to come up with all the new models...
         About app.config, we have heard that request and if you can send me an email @ vishal.joshi@microsoft.com on this then I will try to follow up with appropriate people to see if we can consider doing it...  Essentially more the votes the easier it is to push up the priority...
  -Vishal

• 

  Hi Ericmatz,
       I would like to understand your scenario better about trying to keep Staging, Testing etc configuration in sync with Release configuration... Could you please drop me an email at vishal.joshi@microsoft.com... Thanks much...
  Vishal

• 

  Moemeka
         You will soon be able to get your hands on the new UI... It is worth the wait...
  -Vishal

• 

  JoeChung,
        I talked about this at PDC as jgd12345 is mentioning...  Anyways to give you an idea  if you want to a appsetting in web.config during deployment you will have to write below code with XSLT
   

  <?xml version="1.0" ?>

  <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">

  <xsl:template match="@*|node()">

    <xsl:copy>          

      <xsl:apply-templates select="@*|node()"/>

    </xsl:copy>

  </xsl:template>

  <xsl:template match="/configuration/appSettings">

    <xsl:copy>

      <xsl:apply-templates select="node()|@*"/>

      <xsl:element name="add">

        <xsl:attribute name="key">NewSetting</xsl:attribute>

        <xsl:attribute name="value">New Setting Value</xsl:attribute>

      </xsl:element>

    </xsl:copy>

  </xsl:template>

  </xsl:stylesheet>

  
  with Xml Document Transform you will just have to write xdt:Transform=”Insert” next to the appsetting node you would like to insert...  Essentially huge simplicity is one of the big reasons for doing so...
  
  Additionally you can write your own transform which can be xdt:Transform="XSLT" and invoke XSLT if you like...
  
  Hope this helps!!
  -Vishal

• 

  You are correct. The syntax that matches the web.config format is a lot easier for people to understand who aren't familiar with XSLT.