JoeAudette.com

In VS.NET 2003 in order to open a Solution containing a Web project, you had to have a virtual directory in IIS mapped to the folder of the web app. You could work around this by using class library projects for web development instead of Web projects, though you still had to setup the virtual directory for it to actually work. I've used this approach in mojoPortal because it solved another problem where VS.NET 2003 Web projects do not work well with Subversion clients like TortoiseSVN because VS 2003 doesn't like the .svn folders in web projects. It works just fine with class library projects.
For deploying web projects in VS 2003 (whether they are configured as web projects or configured as class library projects) I'm a huge fan of the free VS.NET plugin UnLeash It, which makes it very easy to deploy just the files needed without the code behind source files. To prepare for deployment on a linux server using mono/apache, I would just choose Release mode then choose Rebuild Solution from the Build menu (this would avoid the default incremental build in VS.NET that doesn't work on mono).  Then I would right click the web folder and choose Deploy Project (a menu item added by Unleash It).

Building a Web project in VS 2003 would compile all the web code files into a single assembly and place it in the /bin folder beneath the root of the web source tree. The bin folder and its contents were not actually included as part of the VS 2003 Web project as far as VS 2003 was concerned. The actual files included in the project are determined by the .csproj file.

In VS 2005/ASP.NET 2.0, things are quite different, here are my observations:
 
It is no longer needed to configure an IIS virtual directory to open a solution with a web project. VS 2005 has a built in web server that it uses for debugging so if you hit the play button and start debugging it launches the app in the browser without the need of IIS. VS 2005 web projects don't mind the .svn folders and play nicely with Subversion clients like TortoiseSVN.

There are no such thing as project files like .csproj in VS 2005, everything in the web folder is considered part of the web project. This means that for example the bin folder if it exists below the web is part of the project.

If you Build a VS 2005 Solution with a web project and there are no other projects in the solution it will not even create a bin folder. If you have other projects in the solution like say a class library with business logic and a class library with data access code and you have references from your web project to them, it will create a bin folder and put the compiled business and data assemblies in there but you will not see the web code assemblies in the bin folder after building. Instead the compiled web code will be generated on the first request and stored in a temp folder beneath C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files.

If you are not using an IIS Virtual directory but using the built in web server in VS 2005 you will also see some source files in the temp folder which are the partial classes containing control declarations and such. In fact you are not allowed to declare controls like TextBox, Label, etc in your code behind files. Doing so will result in errors when you try to build or run your web app because the runtime (and/or MSBuild I think) is in charge of generating partial class files containing the control declarations so adding them yourself will result in duplicate declarations. The above feature as far as I can tell is not yet implemented in mono. If you put the same source files that you used on windows in a virtual directory on linux/mono/apache configured to use the 2.0 runtime you will get errors because of the missing control declarations. If you add the control declarations to the source it will autocompile on mono and work just fine (at least the simple tests I have done work, not so sure about more complex things) but if you use that same source code on windows with IIS configured to use the 2.0 ASP.NET it will raise an error due to the duplicate control declarations. While in VS 2003 I could compile on Windows and deploy on linux/mono and it would work, compiling in VS 2005 and deploying on mono does not currently work. Since auto compilation of ASP.NET 2.0 source code does seem to work I suspect you could precompile from source on mono but I have not tried this yet.

VS 2005 has a feature to precompile your web app so you can deploy it without source code if you right click the web project and choose Publish Web Site. This will copy everything needed without the source files into a new folder tree outside the VS solution and will include the compiled web assemblies in the bin folder. When you do precompile the web project it does not all go into one assembly as it did in VS 2003, instead it goes into a number of assemblies some of which appear to be randomly named. You do have an option to make it compile a separate assembly for each page or control which is pretty nice because you can re-deploy part of a web project without re-deploying the whole thing. In VS 2003 it was a one shot deal since everything was in 1 assembly which could be a problem in cases where you had new features you were not ready to deploy but you wanted to fix a bug in an already released feature you could not deploy the fix without also deploying the new features. This problem is solved in VS 2005 because of the more granular assembly structure. You can get even more control over VS 2005 web project compilation and deployment using the new Web Deployment Projects which was not included in VS 2005 but is available as a beta at http://msdn.microsoft.com/asp.net/reference/infrastructure/wdp/default.aspx.

Update 12/15/2005: Scott Guthrie blogged about a new Web Project Model coming for VS 2005 that will make it possible to do things similar to what we did in VS 2003. For example we will have the option to compile the whole web into a single dll as before. It will use project files like VS 2003 so that only files listed in the .csproj file will be considered part of the project even if other files live on disk within the same folders. Most important we will have the option of making the partial class files with the control declarations live on disk as part of the project. In short, all the things I was worried about in terms of continuing to work with developers cross platform with MonoDevelop as I mentioned in my previous post will be fixed by the additional project model. Excellent!

Update 12/18/2005 Scott Guthrie has posted a link to a new site with more information on the new old way of doing things style Web Applications for VS 2005. You can even get a preview download with some of the functionality working. I'll be trying it out this week.