Rethinking ASP.NET Project Models
I've been thinking again about the compilation and deployment models used in MonoDevelop for ASP.NET code, and it isn't easy to come up with a good solution. I've written a discussion of the various possibilities and how they mesh with MonoDevelop and the Visual Studio way of doing things.
In VS.NET 2003, the Web Application model necessarily used the 1.1 CodeBehind model. This enforces no constraints on project layout at all; all the compiler has to do is compile all C#/VB.NET files into a library in the bin folder, and deployment is similarly simple. In order for controls in the inheriting pages to be accessible from the CodeBehind class, they must be added as fields to the CodeBehind classes, which the IDE does when the visual designer is used. This is the model that MonoDevelop uses at the moment.
The initial release of Visual Studio 2005 replaced this with the Web Site model. All CodeBehind code is compiled into a library by the server when the relevant page is hit, and any additional code must be in the App_Code directory. The CodeBehind classes are partial classes, and the server's compiler generates another partial class containing all of the controls in the inheriting class, so that they can be accessed by the CodeBehind. Everything gets deployed; alternatively, the site can be edited in place. There is a program called aspnet_compiler.exe, which can be used to precompile all the code, and even the pages, and it can be invoked during the deployment process. The major strength of this model is the capability to perform in-place editing. It is also the only model supported by Visual Studio 2005 Express.
A later addition to Visual Studio 2005 was the Web Application model. This is very similar to the VS.NET 2003 model, except that it uses partial to make inheriting pages' controls accessible from CodeBehind. Since Mono's mcs compiler supports partial classes, MonoDevelop could use this model for websites targeting either the 1.1 or 2.0 runtimes. The downside of this is that it would make compatibility with VS.NET 2003 harder.
The real difficulty of designing the ASP.NET project model in MonoDevelop is in trying to support both the Web Site and Web Application models. In order to appeal to migrating developers, we really need to support both models, especially as Visual Studio will be supporting both models in the future. Do we try to merge them into one? Write a project model that's so flexible that it supports both paradigms, but is horribly confusing? The thing is, the two models are designed for fundamentally different purposes: a Web Site for quick-and-easy projects, or a Web Application for a controlled development cycle.
If I were to design a single project model with no regard for compatibility with Visual Studio projects, I'd have a strict file layout like the Web Site model, with all code in App_Code. The IDE compile phase would then compile all the code that would not be compiled by the Web Site model, allowing more control over compilation where necessary. All CodeBehind would use partial classes.
In summary, the big choice is between having separate Web Application and Web Site project types as Visual Studio does, or folding them into one composite model, or having an overwhelmingly configurable project type allowing all development models as options. The big concerns I have are are usability, and compatibility with Visual Studio, particularly VS.NET 2003/.NET 1.1 as it does not allow the use of partial classes.
I'm not sure how much VS.NET 2003 is used now, and developers can of course port their apps via Visual Studio 2005. I'm leaning towards having separate Web Application and Web Site project types, and only supporting ASP.NET 2.0.
I would welcome any insights and ideas that people can offer.
Comments
Web Site model not strictly true.
I do not believe your description of 2005's Web Site Model is strictly true.
If I create a new Web Site using Visual Studio 2005, the codebehind files are not placed in App_Code, they are placed in the same directory as the ASPX files. App_Code can be used for files to be auto compiled like you said, that are not code behind files. For Example a class that doesn't inherit from Page or Control. The case here is to support the good practice of keeping classes in files named after the class and one class per file (or less if using partial classes).
Does this help with the model?
Personally I would support the Web Application Project mode, as that is the one that I prefer to use :)
How can I help with support for this, and or aspnet_compiler?
Oh, that makes more sense
Thanks for clearing that up about the App_Code folder; I've now fixed it in my post. I think I just let my practical unfamiliarity with Visual Studio show through ;)
I guess the code structure for the two project types isn't so different. It might not be so hard to create a hybrid model by having a Web Application that just ignores files that are set to auto-compile (i.e. referred to by a CodeFile attributes). That would allow both styles of development without enforcing either one, and wouldn't be too confusing. Actually, I really like that idea, as my preference is for Web Applications too, but I don't want to shut out the Web Site mode of development. The big question still is what the minimum requirement should be — 1.1, or 1.1 and partial classes, or 2.0?
Last I checked, Mono didn't have an aspnet_compiler. It's probably not all that hard to write, as to a large extent it just replicates the functionality of the framework, and since it's non-critical for web apps it's unlikely to be a priority. It would be nice to have, so if you would like to give it a shot, just drop an email to the mono-dev mailig dist to check if anyone else is working on it.
I'm working on a lot of the basic stuff for the Monodevelop 1.0 release, but if there's anything you'd like to contribute, I'd be very grateful. Just drop me an email before starting anything!
2005 App Project Is A Must
As a Web Developer who started out with the "Web Application" project when .NET first came out and then migrated to what I consider to be the "hobbiest" project style of "Web Site" I can tell you that the "Web Application" project type is much better all around.
I know some people like the "Web Site" and sometimes site that it is more flexible but as a developer working on a mid to large team the "Web Site" project was a nightmare.
The addition of the "partial" classes is a true blessing and my team uses it in our framework coding as well because it makes it easier to break up responsibilities between programmers.
While the 2005 "Web Application" project is slightly different from the 2003 (1.1) version, going forward it is not only a better model but is also being used for Microsoft's AJAX enabled Web Projects.
I personally do not see anyone coming into MonoDevelop expecting Visual Studio 2003 as the basis of compatibility. That is a legacy IDE. If anything, you should make sure that the project types in MonoDevelop match what is available in Visual Studio 2005 and Orcas.
I loved the 2003 implementation of the "Web Application" project and feel that the 2005 sp1 implementation is a stepping stone to a better model for all types of developers.
You comment that Visual Studio Express uses the "Web Site" project type only. This is true, however, members of the Express team have mentioned that newer versions may/will include the "Web Application" project type.
I think your best bet is to include both the "Web Site" project for compatibility with the FREE version of Visual Studio but also the 2005 implementation of the "Web Application" project type as it is more inline with the present and future of ASP.NET development.
On a side not, the 2005 implementation of the "Web Application" project includes the optional "Settings.setting" file (I'll have to double-check but I believe that is the name). This is just a datagrid based GUI providing access to settings such as Web Services from the Web.config file. Is that truly needed.... well, maybe not but it is a nicety.
Good Luck
-Kevin
Another difference with Web Site
Another difference, and imo problem, with the "Web Site" type of project is that there isn't really a project. It's just a folder referenced from the solution file, and all files and sub-folders are automatically included in the "project". It's all very implicit, and the only way to exclude files is to give them the extension .exclude or to make them hidden in the file system. Folders can only be excluded by making them hidden.
I like the explicit "Web Application" model much better, where you can have files and folders beneath your web app folder without them being automatically included in the application without your consent. You have to actually "include" the file in the project for it to be available, compiled, etc.
Yes, I'd forgotten about that
I would like it to be possible to use MD to edit websites "in place", so a simple choice between "implicit" and "explicit" mode would be good. Combine this with FUSE, and you almost have Web Site mode.
WebApplication and not WebSite
I understand your dilemma, but I don't think that you have the resources to maintain the two models. Because of that I think that for now you have to choose.
I prefer WebApplication and in my VS2005 projects I don't use WebSite model. I simply don't like this model... but it's only me...
Hope I could help
Paulo Aboim Pinto
Odivelas - Portugal
In the short term
In the short term it's definitely going to be the Web Application type, but I don't want to make architectural decisions that will preclude easy implementation of the Web Site model or Web Site-like features in the Web App model.
Precompilation
Actually i would prefer if the site could be compiled to a dll prior to using putting it in the web server so that the webserver only had to load the precompiled dll. That would make the web server a bit faster during development.
aspnet_compiler
You need aspnet_compiler.exe, which can perform various forms of precompilation (including the actual pages IIRC), but we don't have this on Mono yet. The Web Application project type does have precompiled CodeBehind.