Web Application Deployment

First off, thanks to Gomez for getting me to look at this issue.

The walkthrough explains how to deploy a basic web application, creating a "Web Setup Wizard" project, etc. It creates an MSI installer package that creates a virtual directory in IIS and copies the files to it. I went one step further and created a web application that was dependent on a "business object" project.

So in the Deployment project, you add the "Content Files" and "Primary Output" categories for the default web project. To support the dependent business object project, you simply "add" again, and this time choose the "Primary Output" files from the supporting business object project. (There is a "project" dropdown in the "Add Project Output Group" dialog.)

Tidbits

• In the deployment project, right side pane, right click on a category and select "outputs". Shows you what's currently in the list to be installed.


• Probably obvious, but "Contents" are aspx and config files (text stuff), and "Primary Output" are the assemblies from the project.


• Also obvious, but you can uninstall through the IDE with right click, Uninstall, or in Control Panel, Add/Remove Programs

Why does the runtime c# compiler fire up when I first access the pages?!

I couldn't figure this out for a while - why do I see csc.exe fire up - thinking that I've "built" my web project in the IDE, then installed it - we should be "good to go" the first time someone hits that site. But here's what's happening.

When you install, the text files (aspx, as*x, web.config) are put in the application root directory, and the "code behind" and other supporting assemblies are put in the bin directory. When you first access the page, the runtime detects that the aspx page you are hitting has not been compiled yet....so it compiles it on the fly and puts the output in the Temporary ASP.NET Files\blah\...subdirectory.

You can look at those files with ILDASM to prove to yourself that your page gets compiled there. So...your web site is actually coming out of two locations:

1. The compiled aspx page code is coming out of Temp ASP.NET files subdirs, even though the source for these script/text files is in the appilcation root. This file will have a class like ASP.WebForm1_aspx that extends WebApp1.WebForm1 (the code behind file)


2. Your supporting assemblies (including the code-behind classes) are being run out of the application\bin directory. This file will have a class like WebApp1.WebForm1 that extends System.Web.UI.Page

Additional notes:

• your assemblies are actually "shadow copied" to some other directory by IIS so you may write over the assembly with a new version without stopping the web server
  

During Development...

When developing a web app with the VS7 IDE, even when you change only the CodeBehind page, sometimes the .aspx page gets saved as well. So when you build the project, the code-behind component will be compiled and ready to go, but the aspx page is now newer than the last compiled version the runtime has seen, so when you first access after an IDE build -- you will see the runtime c# compiler (csc.exe) kick in.

However, even if the aspx page does NOT get saved (and still has an older timestamp), you will still see csc.exe when you first access the page. The reason is that the aspx page has a dependency on the CodeBehind class. So since the CodeBehind class is newer than the page, the page must be recompiled.

You can see this dependency in the "temp asp.net files" directory where the temp assemblies are stored. There is an XML file in that directory for each aspx page (and global.asax). The xml file lists the dependencies of the page, so the runtime will know how to check for "out of date" files.

WOOT!!