So I’m finally getting around to taking a look at the ASP.NET 2.0 Web Projects tonight. I’d been meaning to do this but was a little put off by the ‘pretty raw’ comments from a few people I trust. And no doubt this tool has some rough edges yet, but you can easily see how it works and where this is headed. Well, I’m in the process of consolidating all of my various notes and entries on compilation and deployment into an article and I figured I better take a look at this before putting this together.

The tool basically provides a project model that is very similar to VS.NET 2003 projects. You have a real project file (not a file based structure) that files have to be added to explicitly. Files aren’t picked up automatically based on the directory structure as is the case with the default ASP.NET projects. Instead you have manually add files to the project, which is like all other projects in VS.NET. The project has most of the project features you’d expect a VS.NET project to have including the Project property sheet and an MSBUILD File that backs it all. You can set compiler directives directly, the project can go under source control.

The other big win in my opinion is that once you start adding files to the project and you build it, it builds like it did in VS 2003: You build a single DLL that gets compiled and stored in the BIN directory. Which means in place compilation is back and you can copy files directly out of your project directory to the server without having ASPNET_COMPILER muck with your files and changing timestamps on you. Yay!!! 

In stock VS2005 Web Projects Web compile using ASPNET_COMPILER, into a separate directory copying all the files in your project to a new path. ASP.NET also creates one assembly per source file initially so there’s all sorts of disk trashing and individual process starts as the compiler fires up and compiles. No wonder that this is slow. With the new Web Projects everything compiles into a single assembly and it seems a lot faster. Ok I didn’t create any large projects yet and I can’t just import an existing project by copying files, but on first try with a few pages it looks great.

This also addresses another problem: Control and Page referencing. ASP.NET 2.0 by default creates individual assemblies of each control and page and there have been major issues in referencing other pages and User controls and master pages dynamically at runtime. Unless you explicitly import the Page/Control via the @Register directive in the page it can’t be referenced as a strong type. So the Web Projects sidesteps this issue by compiling every piece of code in the Web Project into a single assembly so everything can reference everything else in the same assembly without any issues.

This model generates a single assembly of all the source code in your project, but I’m not sure that it is going to be able to create a single assembly that also includes the generated ASPX code, so that like with a Precompiled Web you can deploy a single assembly (plus any reference assemblies) to run your app.

This model is very similar to VS2003, but there are a few improvements, most notably that it doesn’t use FrontPage extensions to connect to a Web, but rather uses raw HTTP connections and interaction with the local machine IIS installation to figure out the location of the project.

Not all good

Ok, so far so good. But now for the bad news: These projects use a different code generation scheme. Which means if you have existing ASP.NET 2.0 pages and control they won’t work as is. I have a fairly large ASP.NET 2.0 app that I have ported up from 1.1 and painstakingly updated to 2.0. I tried to import that into the new project, but it turns out that won’t work. It looks like from some of the support documentation and posts that this will somehow be supported in the full version but right now there’s no two-way back and forth support between a stock project and these Web projects.

Specifically Web Projects creates 3 files for each page: The ASPX page, a codebehind page with a partial class of your code and a designer page. If you’ve used WinForms in VS2005 then you know what this will look like. The designer.cs file basically contains all the control definitions and event hookups that in stock ASP.NET 2.0 pages are generated on the fly. The idea is that this tool doesn’t use ASPNET_COMPILER to do the dynamic code generation at compile time, but rather it uses the stock CSharp/VB compilers to compile an already fully generated page class. It’s the same stuff that used to be generated into the actual source file in VS2003 in the Web Designer Generated section of the page with InitializeComponent and OnInit() with the added benefit that partial classes allow separation of the file. This means we’re back to design time code generation…

The difference is that ‘normal’ ASP.NET pages in VS2005 generate the partial class that contains controls and event hookups dynamically at compile time based on the ASPX script page. In Web Projects, this generation is shifted to design time now. Actually – in this preview release – there’s no code generation at all – you have to do it yourself by adding control definition and event hookups manually into the designer source file. Ouch!

I’m assuming based on the comments in the designer page that the generation will happen automatically in the future. We’ll have to see how this works out. I’m a little worried about going back to design time generation and all that entails - keeping the designer and files in sync was the cause of much frustration in VS2003 after all and we can only hope that this tool does a better job of not mysteriously loosing event hookups and other declarative tags.

I hope the designer files can be generated at any time, so that you can drag and drop a file from disk that is from a stock 2.0 project and that it then automatically generates the designer file. This would make it possible to run pages either with the new projects or with stock projects which would just ignore the designer file. The key is really that the designer file must be easily creatable and be guaranteed to stay in sync unlike the VS2003 implementation <g>. I think the ASP.NET team is fully aware of this issue and I would expect this to be the case.

The other ‘issue’ with this model is that we loose a few cool features of the stock ASP.NET 2.0 model. Specifically you loose the partial compilation functionality for debugging and testing. One feature that I like a lot in ASP.NET 2.0 is the fact that you can debug a page, make a change to it and keep on running without recompiling the entire app. ASP.NET recompiles just that one assembly and so doesn’t need to restart the app entirely. No AppDomain restarts, no debugger hookup etc. That feature is gone with the Project Model. On the other hand compiles should be much faster and startup potentially isn’t that much slower than the simple restart. In my current setup debugging VS2003 apps is still faster even with a full recompile app restart than making a change and re-running the page in a sizable application.

So ultimately what we have here is a parallel development model to the stock ASP.NET 2.0 support in VS.NET. Assuming that this tool gets all the bells and whistles that we take for granted in the stock ASP.NET projects (View Code, View in Browser, hotkeys, Debug etc.) this option looks very promising.

It’s not clear at this point whether it will be easy to go back and forth with. I hope that you will be able to do this, but we’ll have to see how this turns out. But you have to make a choice one way or the other. I think for the way I like to work, this project model is a better fit even though you loose some of the simplicity of stock File Based Project model.

I also worry about the ‘after market’ issue. I ship a lot of projects and tools to customers and for download etc. If you really embrace this new model you are then requiring your customers to have this tool installed as well. Likely Microsoft will release this as an add-on unsupported tool and some customers may balk at that. Hopefully this will integrate into VS.NET natively with the next service pack.

If it does get integrated, I’m going to guess that this model will be widely embraced by developers in the know. Although a little more complex in concept the little bit of added complexity is far outweighed by the benefits: Single DLL output, In place compilation, page/control referencing, faster compiles and easier deployment…

Too many freaking choices?

I’m glad Microsoft is addressing these issues with tools, but I am getting a little concerned with the many, many options that are now available to deal with page compilation, project management and deployment.

Choices are good, but man, it’s getting downright confusing to pick the right mechanism for compilation, projects and deployment. You can work with CodeBehind, or in-place editing. Now add CodeBehind with the designer. For compilation you can use 1.1 style compilation and page set up or 2.0 style with partial classes. For deployment there are about 20 different ways to compile a project in combinations when you add in the Web Deployment Project tool.

If you’re the average Joe, who’s starting out with ASP.NET they are not going to know which approach is best for them. And to do it right you really need to use the new add-ons (Web Deployment Projects or now this Web Projects tool). I really hope Microsoft can integrate all of this functionality directly into VS.NET and Visual Web Builder rather than making these things add-ons.

For Compilation I’d like to see something similar to my compilation tool (in terms of UI and options) so you can see all of the options at a glance and you can experiment easily with them, which given the many options I think is important.

For the new Web Project, I think it would be nice if you could compile into a single assembly somehow, so that ASPX pages don’t need to be deployed at all. Right now Web Projects seems to mimic the ASP.NET 1.x model of compilation which still leaves the ASPX pages on the site and being dynamically compiled at runtime. If we’re already reworking this process, let’s go all the way and provide a mechanism to compile all that ASPX code into another or even the same assembly for packaging. That way you can upload 1 or 2 assemblies and be done with it without having to worry about keeping ASPX files in sync. The ASPX files can stay as placeholders for Authentication if Windows Auth is used. I think that single assembly compilation continues to be one of the most sought after goals and this provides another chance to provide it (the other being the Web Deployment projects).