Rick Strahl's Web Log

Wind, waves, code and everything in between...
ASP.NET • C# • HTML5 • JavaScript • AngularJs
Contact   •   Articles   •   Products   •   Support   •   Search
Ad-free experience sponsored by:
ASPOSE - the market leader of .NET and Java APIs for file formats – natively work with DOCX, XLSX, PPT, PDF, images and more

Taking the ASP.NET 2.0 Web Deployment Projects for a Spin


So I ended up updating my West Wind Web Store app today to use the new Web Deployment projects and I’m happy to say that it worked fairly smoothly. It did take a little while of experimenting to find the right combination that I think will work best for me.

 

The Web Deployment projects is essentially a tool to simplify project compilation into a more manageable deployment scenario. The biggest beef I have with the stock ASP.NET 2.0 behavior is that you are not able to build a compact install that is repeatable – the smallest default compile option is to compile into one directory per directory and the assembly name in that scenario is randomly named. In addition the compiler generates dynamically named .compiled files for each page, which was a complete mess for deployment.

 

So this new project type which is in essence a fancy build script that works with a new utility the ASP.NET team published called ASPNET_MERGE.EXE. This tool allows combining assemblies into a single compact assembly (or still one per directory) and it does so by giving the assembly(ies) a predictable and repeatable name. This is the way it shoulda been out of the box

 

So as I see it there are really two compilation options that make sense here:

 

  1. Compile into a single assembly including compiling ASPX code
  2. Compile into a single assembly with updateable ASPX pages

 

#1 seems really tempting – compiling all code into a single assembly including the ASPX sure would be nice, but there’s a caveat: It leaves you with stub ASPX files which are required (if you need NTFS security) and you still end up with a shitload of .compiled files in the BIN directory, one for each page and user control in your project. On the upside the .compiled files are fixed in name so you unlike with the stock compile you don’t have to recopy the files each time and wipe out the old ones. As long as your site hasn’t changed and added new files you can simply copy up a new assembly or if things have changed you can simply grab all of the .compiled files and update them without having to worry about a old files being left over.

 

Still I don’t like this idea of the .compiled files and the stub files. It’s two sets of files that need to be managed, plus you loose the capability to make a quick design change to an ASPX page.

 

So I have used #2 to deploy my site at this point which pretty much mimics the ASP.NET 1.1 behavior where you have full ASPX pages that get compiled on the fly and an assembly that provides all the ‘code behind/beside’ functionality in a separate DLL.

 

I had a scary moment when I copied the site up to the Web Server – I compiled the project without the option of creating a App_Code.compiled file locally and tested the site in staging and it worked fine. I copied everything up to the server and I got… drum roll – blank pages for every page request. No error, no message, just a blank page. I realized the issue recompiled and popped up the App_code.compiled and everything started working immediately.

 

Interestingly enough while testing both setups I wanted to compare performance – it would seem that #1 would be considerably faster loading than #2 as the ASPX pages wouldn’t need compiling. Although this site isn’t huge there are about 20 pages/controls in the root of this app and I didn’t notice any significant load difference between #1 and #2.

 

ASP.NET 2.0 seems to be pretty slow loading in my experience – and the load time apparently has little to do with parsing the ASPX pages on the fly and all to do with loading up the .NET runtime and bootstrapping ASP.NET and JITing the application itself into machine code… Some people have mentioned this as well and while I see it, I’m not too terribly concerned. I can live with slower startup in trade off for the overall faster performance that I see in my apps. I’ll take faster running perf over slower startup speed any day

 

Overall this utility has already made my life a lot easier. It’s going to be a breeze now to update my site and I will most certainly be updating more frequently than I have been in the past. Kudos, for the ASP.NET team for listening to some of the community complaints and providing a solution. I hope that this sort of deployment functionality will make it into the stock ASP.NET compiler in the future as it should be a core feature not an add-on… I suspect many people are not going to find this tool soon enough and be frustrated with the stock ASP.NET compilation behavior.

 

Now playing: GrunTruck - Tribe


The Voices of Reason


 

hagay
November 21, 2005

# re: Taking the ASP.NET 2.0 Web Deployment Projects for a Spin

i found this nice addon for vs2005 , kinda fixes most issues, at least so it seems

Chris.gd
April 11, 2006

# re: Taking the ASP.NET 2.0 Web Deployment Projects for a Spin

Thanks for clarifying.

Don't know what Bill was thinking when he didn't integrate this into VS.NET2k5 for it's grand release.

Anyway, life goes on.

# DotNetSlackers: Taking the ASP.NET 2.0 Web Deployment Projects for a Spin

 

West Wind  © Rick Strahl, West Wind Technologies, 2005 - 2017