Your official information source from the .NET Web Development and Tools group at Microsoft.
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) 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 (currently in Beta2). You can download MSDeploy from below location:
Do note that installing Visual Studio 2010 will automatically install MSDeploy for you. Visual Studio 2010 CTP can be downloaded from below location:
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.
Vishal R. Joshi | Program Manager | Visual Studio Web Developer
Great that is all us IIS admin need is devs trying to deploy apps on the servers *sigh*
Devs shouldn't deploy websites. We are Microsoft encouraging this!
This new feature is good . But if the data base size is very large what happend. will that be possible to deploy that also ?
>>Thanigainathan: DB size
Hi Thanigainathan, we are using standard SQL Management Objects (SMO) for scripting the DBs... As this is a SQL server service we should typically work okay...
Can you share the approx size of the DB that you have in mind...?
My latest in a series of the weekly, or more often, summary of interesting links I come across related to Visual Studio. John Kilmister has created a XAML for WPF Cheat Sheet and it is available for download (.pdf). Greg Duncan posted a link to the WPF
"Believe me we did put some thought in that area too... Again it is not coz we did not want to do it but due to various longer term considerations around doing it right..."
Ok, this is important: Microsoft doesn't have to do it!
I strongly suggest your team look at Migrator.net (1). See if it's possible to contribute to that project and make sure that it can hook into your tools. Why reinvent the wheel? It's just like MSTest, there was no need for that, and I just use xUnit.net, because it is so much better. By the time you have the resources to create a migrations framework, you'll be way behind and that would be a waste of effort.
>>Rovstar: Great that is all us IIS admin need is devs trying to deploy apps on the servers *sigh*
Hi Rovstar, we are not encouraging developers to deploy web applications directly on the production server... In fact the goal is to make the developer to server admin hand off being less error prone than what it is today... In subsequent posts you will see how the concept of packaging will introduce tremendous amount of transparency in the hand off process and how there are possibilities where developer/server admin documentation can be hugely reduced due to self describing and human readable nature of the packages...
Stay tuned and in the meantime feel free to send me an email at Vishal.Joshi@microsoft.com in case you would like to have further detailed discussions...
Hi Mike, it is possible to hook into 3rd party frameworks like MigratorDotNet with the current web deployment model... In fact migrator.net comes with msbuild project/file and the new web deployment model is also designed on msbuild so it should not be very difficult to plug it in...
It is in my "TODO list" to take some examples like migratordotnet and demonstrate how they can be easily plugged in, so please stay tuned on that... But before I do that I will most likely land up explaining the extensibility and then maybe someone from community can get to it much before I can... :-)
Argh! After I spend so long perfecting my deploy tool this comes out :)
No matter, I still have a few things in there that this doesn't. It sounds great however especially since I'd be able to add my custom work tasks in.
Will this be combined into TFS / MSBuild as well?
Vishal: Yes there will be full integration with TFS/MSBuild so you will be able to completely automate this process...
Is this going to work *ONLY* on web.config? What if I have split parts of my config into other *.config files - can I apply transforms to them as well??
>>Marc: web.config transforms to other .config files
Web.Config transformation can work on any XML file... It is actually pretty generic that way... There will be a tiny bit of customization required, but we will put a blog post on how to do that...
Tracking back to MVP Global Summit 2008, the ASP.NET team was trying to get ideas from a bunch of ASP
XDT certainly will be useful to some, but those of us that have a knowledge investment in XSLT or XQuery are going to be very frustrated that there isn't direct support for those languages.
Sure, for most trivial apps, XDT will produce smaller code (at least than XSLT/XPath 1.0), but size shouldn't be the primary determining factor, or we'd all be programming APL.NET or IronPerl. Besides, XQuery would be even smaller, since it doesn't require the trappings of XML.
Shouldn't there be choice of transform language for developers, just as with GP progamming languages? After all, Microsoft isn't killing VB anytime soon, are they?
I suspect the biggest part of the problem is the lack of an XSLT/XPath 2.0 processor in .NET.
I am attempting to answer your comment inline… Please feel free to write me an email at Vishal.Joshi@Microsoft.com in case you would like to discuss further…
“XDT certainly will be useful to some, but those of us that have a knowledge investment in XSLT or XQuery are going to be very frustrated that there isn't direct support for those languages.”
>>Vishal: XDT has been made completely extensible… I do not remember the exact syntax [I will write a post on that too…] but what transforms like “Replace” etc are doing is accepting the original web.config’s node, accepting the web.transform.config’s node and giving back a new node to the engine… The engine calls all the transforms and the new web.config comes out… The reason for explaining this is coz one of the Transforms (similar to “Replace” etc ) that we were hoping to write was “XSLT” which could take a xsl file and produce the output… It should not be difficult we just never got to it due to time and resource issues… But we certainly have the extensibility and all the inbuilt transforms are written in the same way, implementing the same base classes… If you like we can work together with you to have a community release of “XSLT/Xquery” plugin for XDT… IMHO it will be pretty cool and I am sure many others who have already invested in these technology will benefit from it too… Do drop me a line in case you would like to do so…”
“Sure, for most trivial apps, XDT will produce smaller code (at least than XSLT/XPath 1.0), but size shouldn't be the primary determining factor, or we'd all be programming APL.NET or IronPerl. Besides, XQuery would be even smaller, since it doesn't require the trappings of XML. Shouldn't there be choice of transform language for developers, just as with GP progamming languages? After all, Microsoft isn't killing VB anytime soon, are they?”
>>Vishal: The idea was that for simple stuff 80% of web developers would be able to have good transformation model without huge learning curve and they can continue focussing on building their webs instead of struggling with this aspect of deployment; you will not believe how many people do this manually today due the complexity of XSLT; but nevertheless I agree with you that we should have a way by which you can choose your transform language… Again, we would love to work with you to come up with a model that we can recommend to the rest of the community…
Yes there will be full integration with TFS/MSBuild so you will be able to completely automate this process...