One of the most difficult things about developing ASP.NET project support for MonoDevelop is deciding upon a project model to use. Microsoft appears to have this problem too; while having used a "Web Application" (WA) model for VS.NET 2003, and then switched to a "Web Site" (WS) model for Visual Studio 2005, they have just recently brought back the Web Application model for VS2005. Both are sensible and straightforward ways of developing an ASP.NET site, and developers migrating from Windows are familiar with them, so it was clearly a good idea to use them as a starting point when planning how to implement the project support in MonoDevelop.
Initially I aimed to combine the two models, so I first looked at the most obvious difference between them, the implicit/explicit file listing: WA has an explicit list of files, but WS considers all files within its directory to be part of the project. Both behaviours could easily be available in one model as a project option, so no problems so far. The difficulties occur when one considers why WS's implicit listing is useful.
The WS model has a major advantage over WA in that it can be used directly to edit a running site on a remote server. While not ideal for structured development or precise control, this is nonetheless an incredibly useful feature and is, in my opinion, the more useful of the two models. All files present in the application folder on the server are therefore part of the project. One requirement of WS is that there should not be a "project file" on the server, but neither can there be a local project file used to store settings, or different developers working on the same site will get out of synch. On the other hand, WA requires a project file, at the very least to store the file list.
An important question is how the "Web Site" fits into MonoDevelop's project system. As it stands, MonoDevelop relies entirely upon having project files of some kind. Implementing WS would require modifications to the solution system to allow a new kind of "remote directory" project type, an "Open web site" entry on MonoDevelop's File menu, and an "Add Web Site" entry on the Solution menu in the Project Pad. Making this fully useful would require adding remote file support throughout MonoDevelop, which is a fairly major task. However, all of this work would be very useful for adding support for any other web development framework to Monodevelop.
I believe that "Web Site" and "Web Application" are not merely two different project types implemented by Microsoft, but are actually fundamentally project models.
Some readers might also wonder how the various ASP.NET compilation models fit into all of this. I do not think that they present an issue, as any of them could be implemented transparently under either of the project models. ASP.NET allows use of different .NET languages in different pages, so WS has to support this too. This is not an issue for WA; indeed, for a structured app, limitation to one .NET language is good. This does of course simplify the compilation process in WA. Deployment options are of course very similar for both models.
My current plan is to develop a Web Application project type, as this is by far the easier of the two project types to write, and this will allow me to concentrate on other areas like code completion and integrating the AspNetEdit designer. I do like the Web Site model more, so I will aim to make as much of my code as possible usable by a future Web Site implementation.
I'm still not completely certain that I've chosen the right approach, so I would welcome any comments.
Comments
Re: ASP.NET Project Models
Hi Michael,
Personally I'm glad you are going to implement the WA model. Its what I use in mojoPortal. Nothing wrong with the other model in some scenarios but I prefer in general to deploy just the dlls and markup on production and no source code.
Incidently, in the 1.1 Framework version of mojoPortal we have at least one developer, Dean Brettle, who does all his work in MonoDevelop currently. This works even though the there is no current Web project type because the 1.1 version of mojoPortal was implemented as a Class Library project which is supported in MonoDevelop.
The reason we did this was not for MonoDevelop but because the VS 2003 project type did not like .svn folders. It just happened to turn out that this also made cross tool team development possible between VS 2003 which I use and MonoDevelop which Dean uses. If I add a file it doesn't automatically get added to the corresponding MD project but Dean would add the file if he got a build error as would I if he added one.
There was a hacked version of TortoiseSVN I could have used but I chose to go with the class library approach because it had no problem with the .svn files from sSubversion. I found here how to hack VS to make the web type files show up in the VS Add Item feature for Class Library projects so there was no lost conveniences.
http://www.pluralsite.com/wiki/default.aspx/Fritz/AspNetWithoutWebProjects1.html
MonoDevelop is getting better all the time, keep up the good work you guys are doing.
Cheers,
Joe
Open Source SVN Plugin for VS.NET
You might already be aware but there is an open source SVN plugin for VS.NET available from the folks at Tigris:
http://ankhsvn.tigris.org/
It works but I haven't used it extensively.
Will
Answers
I thought that Microsoft's Web Site model had a range of precompilation option before deployment which would allow you to deploy no code?
The .svn folders will not be a problem here. I've come across that problem before when I was a Windows guy, but I can't see why I'd want to replicate that behaviour. By the way, MonoDevelop can automatically detect new files - it's in the project options.
Anyway, I'm glad my work will be useful to you :-)
It's like this
It's like this. How can we create a dinamically reference to a acx file without having any reference in the aspx file? We can do this with hard-work. Using the namespace we don't have to have a explicit reference in the ascx register zone.
ASP.NET Project Models questions...
Hi, Micheal
You are making an great job. I find that you can implement WA model to allow ASP.NET developmente more easy and later include WS model. I'am developing a CMS and i use a class library project type and just atach my application project to debug. Why don't use a class lybrary project to provide a ASP.NET support in MonoDevelop? This would not be more easy to add this feacture? And later you can work in the WS model.
Sorry my poor english.
...and answers.
To implement WA, I am essentially subclassing MonoDevelop's class library project type, but there is much more to ASP.NET support than this. Of course, I will be able to reuse most of this code in the WS model.
Compiling: Ensure that all CodeBehind classes declare the controls in the derived page, so that they can be accessed from code.
Running: Launch XSP and a web browser.
Deploying: Use GnomeVFS to deploy the compiled site and its references.
Designer: Integrate the AspNetEdit designer.
Code Completion: Code completion of page members in CodeBehind classes. Hopefully also aspx, CSS and XHTML.
Web Application ....
Hello Michael
I think that WS is not the best model to develop a ASP.NET application. Has some advantages, yes, but all can be done in the WA model that I like.
One of the big problems that we found is the manipulation of the BIN directory. Why the bin directory is a application folder? Because of that, the SourceSafe try to add the dll and pdb files and try do check-out. WHY?
Remove the namespace from the WebSite project is another thing that I don't understand. How can we create a dinamically reference to a acx file without having any reference in the aspx file? We can do this with hard-work. Using the namespace we don't have to have a explicit reference in the ascx register zone.
Because of this 2 problems I don't like the WS model and I try to use all time the WA model.
hope I could help in this problem
Paulo Aboim Pinto
Odivelas - Portugal
I don't think those are the best reasons to avoid Web Sites.
Those two problems sound like isses with Microsoft's software, not the fundamental model itself ;-)
Really, WS can do much more than WA, but WA offers a much more restrictive model that is useful if you are trying to develop and deploy in a structured way.
Web Application or Web Site Project Model
Hi,
I honestly think you should aim for the WebSite model; just because it is *so* much easier for the majority of beginner and intermediate developers. Yes, there are benefits of the original Web Application model, but with MONO we must first be aiming at making this an easy platform for mainstream developers and not those heavily exposed to ASP.NET. Please start with the web site model....and only if you get that working try the web application model.
Thanks,
David
As I said...
...that is my ultimate aim.
Yes, WS is my favourite model too, but a lot of people (and a lot of the commenters here) prefer WA. Considering the relative amount of work involved for the two models, I think it is better to get WA and all the common functionality working first.
I agree with this point
I agree with this point. The reason we did this was not for MonoDevelop but because the VS 2003 project type did not like .svn folders. It just happened to turn out that this also made cross tool team development possible between VS 2003 which I use and MonoDevelop which Dean uses. If I add a file it doesn't automatically get added to the corresponding MD project but Dean would add the file if he got a build error as would I if he added one.
---------
software
Project files
> MonoDevelop relies entirely upon having project files of some kind.
Yes, that's because ALL projects have files. Both WA and WS projects have files. In WA projects the file list is taken from the project file. In VS projects, file list will be taken from the project directory (and probably updated using a file watcher).
The Project and ProjectFile classes are only in-memory object structures, which are not bound to a specific file format. In fact, they are not even found to a file at all. You can build Project objects from whatever information you have. Having this in-memory representation of a project is important, because in this way the parser service knows which files to parse, and the solution pad knows which files to show, the source control add-in knows which files to control, etc.
Sorry if it didn't come across clearly
I meant that the project is represented by a "project file". Of course I understand that all projects contain files, and are represented in memory by a project object, which has a list of files in the project.
My point was that MonoDevelop's UI (open/create project) and the solution file format depend on the existence of these "project files". However, the "Web Site" model ideally does not need a "project file" because of synchronisation and deployment issues.
Project files
What I was trying to stress is that projects don't need to be represented by a "project file". For projects which don't have a project file you'll need to implement a custom "open project" command, but it does not imply a change in the solution system. On the other hand, the solution file format does not depend on the existence of project files. Arbitrary URIs should work, as long as there is a IFileFormat which can understand them.
Other directory-based projects
I didn't realise that the solution format would handle arbitrary URIs; that does make things a lot easier.
Nonetheless, handling all directories is a big jump for one project type to take, and there could be problems if other web site types (e.g different languages) are written at some point. This also applies to the project opening UI. Given that such project types would also want remote file access, there is a clear scope for generalising all of this functionality into a base project type.
Anyway, while I believe that implementing the simpler WA model is better because it will give me more time to spend on other features, I would like to tackle this after SoC.
The reason MS had to
The reason MS had to retrofit the web app back into VS.Net 2005 was twofold:
1) Performance.
2) Backward compatibility
Why performance you may ask? Well, the web app compiles less code when the project is built than the web site model (the web site model has to validate that everything is correct - aspx, ascx etc) whereas the web app model merely compiles the "code behind"/app_code content.
This performance issue only really occurs when you have hundreds of pages/usercontrols - and perhaps shows that Microsoft did minimal testing with this scenario before they went with the web site model.
Personally, I love the web site model and would do all I could to continue using it in VS.Net 2005 and beyond.
Not Exactly
At my company, we halted our upgrade to VS2005 until the Web App project model was available. For us it was a show stopper. Not having a project file massively complicates shared development scenarios. We need to deploy to source control. Each user will have files in his directory which should not be deployed... hitting "Exclude" and causing a rename to .exclude was massively poor. Source control lost the file, or there was excessive maintence in keeping track of each developer.
I am glad you chose the App model first. I think it is vastly more appropiate for large managed corporate softare development scenarios.
Only one developer teams work on their site directly on the server.