Before we talk about the reasons why you should create a Web Package let us first understand what is a web package… Web Package is an atomic, transparent, self describing unit representing your web application which can be easily hydrated into any IIS Web server to reproduce your web… It is a .zip file which not only contains your content but also contains its dependencies like IIS Settings, Databases, GAC DLLs, Registry Keys etc…
The concept of creating Web Packages for deploying your web application to an IIS Web Server is recently introduced with Microsoft Web Deployment Tool (MsDeploy) and towards the end of this post I will talk about how you can create a Web Package for your web app… But before going there let me talk about the 10 reasons why you should consider creating web packages for your web application:
- Having all your web content and dependencies like IIS Settings & DB into a single .zip file allows you to easily transport it anywhere…
- If the web package actually contains source code then you can replicate your dev environment to another box relatively easily… Imagine being able to recreate a project on your home machine by simply emailing yourself a .zip file…
- If you are deploying in a web farm environment then deploying the web package to various server boxes will allow you to very easily recreate your load balanced web servers…
- If you are creating software for community to use then sharing web package .zip files with world creates a common handshake model…
- Web Application Gallery, which will be common home to find reusable Web Applications also uses the same Web Package format… So you will have an opportunity to put up your web app into Web Application Gallery if you create a Web Package…
- Most of the Package creation process is very automated so you do not need to write custom actions like you would have to do in case of MSIs…
- Creation of Web Packages can be automated along with your nightly builds really easily using MsBuild with systems like Team Build…
- You can create a web package for various versions of your web application and easily use the versioned packages to roll back to any version you like…
- You get free standardized UI to install the Web Packages in IIS Manager which hopefully will become pretty standard and easy for everyone to understand… If you do not like to use the UI the package can be installed via commandline as well…:-)
- Most of the automated tools (providers) required for packaging your web application and its dependencies are available out of the box (few of which are IIS Settings, SQL DBs, Web Content, GAC assemblies, COM components, Registry keys etc)…
Finally let me mention the out of the box providers which can be invoked when you want to package your web application… You actually have a choice to call any of these providers depending on what parts of your Web Application you like to be packaged… These are my other +20 reasons why you should create a web package…
- File System Directory to move a files & folder which contains your web application files like .aspx, .config, images, .js, .css, .master etc – contentPath
- Creating a new IIS Web Application for your web– iisApp
- Moving IIS7 and above (read Vista, Win2k8, Win7, Win2k8 R2 and above) Configuration Settings associated with your web (e.g. Default Document, ApplicationPool Mapping etc) – appHostConfig
- IIS5.1 & 6 (read XP, Win2K3 compatibility) Metabase Configuration Settings (parallel to IIS7+ settings above) - metakey
- Pulling data & schema from existing SQL Server Database or custom generated .SQL files which your web uses– dbfullSQL
- Any Security Certificates (e.g. SSL & ClientAuth) that your web depends upon- cert
- Any GACed assemblies like 3rd party controls or libraries that your web uses – gacAssembly
- Any custom IIS7+ Application Pool that your web has created– appPoolConfig
- Registry key associated with your webs – regkey
- 32 bit COM Object – comObject32
- 64 bit COM Object – comObject64
- Security ACLs associated with folder – setAcl
- Granular control by pulling just a registry value - regValue
- ASP.NET root web configuration file on 32 bit machine – rootWebConfig32
- ASP.NET root web configuration file on 64 bit machine – rootWebConfig64
- Similar type of support for packaging MySQL DB – dbMySQL
- Packaging Machine.Config of 32 bit machine – machineConfig32
- Packaging Machine.Config of 64 bit machine – machineConfig64
- If there is still a provider missing then you can very easily create one – yourCustomProvider
- A secret provider which I am not allowed to talk about just yet :-), but trust me it is really a killer provider - secretProvider
So now that you have 10 +20 reasons to create a web package let us talk about how to create one… From end developer/IT pro standpoint you can create Web Packages from various different avenues, some of which are:
- Web Packaging from VS 2010 UI
- Web Packaging from MsBuild in VS 2010
- Web Packaging from CommandLine
- Web Packaging from PowerShell
- Web Packaging from IIS Manager
Please follow the links above to create a web package using your preferred method… I hope you are jazzed about being able to archive and deploy your web applications using Web Packaging…
11 comments:
Looking forward to VS 2010 Web Deployment. Thanks.
Wow wow wow...First time I'm reading about web packaging in VS2010...Sounds awesome...
This really would solve many of the problems we used to have while deploying to production servers. We developers do not have access to the dedicated deployment servers used by our company (I guess it is a common security practice). And oh man, it really is a pain preparing the documentation explaining how to do the setup and deployment to the server admin guys. Whew and the countless weekends I had to spend in office undoing all the messups made by them.
Thanks again guys for making it easier for us...
Thanks Sheron appreciate the endorsement... Looking forward to your feedback as you start playing with the product...
-Vishal
Good evening
What about updates ? How does this cope with SQL Schema changes and existing data for existing web applications.
I understand the 'simplicity' for new apps, but how to roll out updates for existing apps ?
Also what about security/ACLS, for example each website on our webfarm we run with a dedicated user for that purpose. The application pool runs under that user and the physical directory would then only have read access for that user, unless specific write access is also needed ? For example how to setup tight security on different directories and associated users ? Local dev servers would/could be running in different domains so ACLs cannot just be simply copied across ?
Thanks
Shane
Great questions Shane...
Currently the DB Deployment which comes as part of the packaging experience does not take care of the incremental DB deployment... Although the good news is that DB Deployment allows you to inject SQL Scripts into the package... You can generate the .SQL files either via RedGate or TS Data do some minimum pre processing to them to make them native SQL Scripts and then inject them into the package as part of standard extensibility... I have a work item to document how to do that, which I will hopefully do soon...
About ACLs - there is a flag which you can set in your project properties (by manually editing the file) to allow packaging to pick up ACLs from the source box and move them to the destination box... You brought out a great point that the ACLs which are set on your Dev box are different than the deployment server... For this very reason we did not make copying ACLs as part of the UI... For scenarios where ACLs are different due to different domains in dev server vs production/staging it is a very tricky problem... I believe in these cases there will have to be some manual intervention required or there will be additional hooks available which you can use to write custom scripts/exes to do the job... Again I understand it is not straight forward but then the basic MSDeploy model is to replicate source to the destination and your scenarios falls outside the bounds of this model to provide an out of the box solution... But nevertheless it will be possible to do this via extensibility that I will hope to write about sometime soon as well...
Thanks
Vishal
Hi, good article and one close to my heart as I'm responsible for our organisation's web application deployments. One question: we still use IIS6 here - will I still be able to create and install web packages?
I do not think you can install web packages on IIS6. Please check Microsoft website for additional information
"I do not think you can install web packages on IIS6. Please check Microsoft website for additional information"
Infact you can install web packages on IIS6, you just do not have the inbuilt UI in IIS Manager... You will have to use commandline to install them...
-Vishal
Hi Vishal,
It's been over a year now. What's the secret provider?
Q. It's been over a year now. What's the secret provider
A. I was referring to "runCommand" provider which allows you to run any batch file, which essentially means that you can do anything else which Web Deploy does not support right out of the box...
Ah. Cool.
Thanks, Peter
Post a Comment