In the last couple of days I've been experimenting a lot with deploying the ASP.NET 2.0 sample website I'm building fom my next Wrox book. I mean deployment in the real world, to a real hosting space. I used aspnet_compiler.exe to precompile the site so that it's faster to load on first request, and especially to protect my code (at least a little bit) from prying eyes. Then I executed aspnet_merge.exe to merge all generated assemblies into a single file that's easier to deploy. The documentation I found most useful was the two DOC files that you can download from this page, which cover the aspnet_compiler.exe and aspnet_merge.exe command-line tools, plus the Visual Studio 2005 Web Deployment Projects add-in. This addin provides an intuitive and easy-to-use UI for the aforementioned tools. For example, you can choose the compile all source files and even the markup of the .aspx, .ascx and the other ASP.NET files into a single assembly by ticking a couple of checkboxes and building the project.
While using these tools to compile and deploy the site I ran into a problem (and its solution) that I thought would be good to report here. When you create web pages in VS2005, it doesn't create the code-beside class into a default namespace, like VS.NET2003 did. So, unless you add it manually, all your pages' code-beside classes will be defined within the default ASP namespace. Now you may wonder: what happens if I have multiple pages called default.aspx, with a _default code-beside class? This is actually my situation, as I have a default.aspx under the site's root folder, another one under /admin, and some others. This wasn't a problem while testing the site with the standard in-place precompilation, because these pages' classes get dynamically compiled into separate assemblies, and therefore there isn't any duplicate type name. Everything was fine until I tried to compile all site into a single assembly (if done manually from the command line, this corresponds to the -o switch of the aspnet_merge.exe tool, in case you're wondering); guess what, in that case the built fails, because aspnet_merge tries to merge into the same assembly multiple ASP._default types! Once the problem became clear, the solution was simple: add an explicit namespace to the pages (in both the .cs/.vb class file, and the .aspx file referencing it through the inherits attribute) that is different for different folders, so that there could be two Default.aspx pages compiled into SampleSite._Default and SampleSite.Admin._Default.
The bottom line is: always use explicit namespaces for all your pages and controls, even if it bothers you to add it manually! In the following couple of days I'll be posting more details about the sample site, and will actually provide a link to explore it online (including the admin section!). Stay tuned.