Why I like Web Application Projects vs. WebSite Projects in Visual Studio 2005
Like myself, many developers found migrating Visual Studio .NET 2003 applications to the new Web site model in Visual Studio 2005 impractical, especially because precompiling (publishing) a Visual Studio 2005 Web site creates multiple assemblies. Lots of other complaints surfaced; they are too numerous to mention, but the good news is that "Mr. ASP.NET" (Scott Guthrie) and his team responded with the new Web Application Project add-in and it's vastly improved, even over the original VS.NET 2003 model. This was all in response to developer feedback (or screams of bloody murder, if you prefer) and the final came out about May of this year, just months after the initial release of Visual Studio 2005.
However, I see from forum and newsgroup posts that a significant number of developers have obviously either not yet found the Web Application Project add-in, or they aren't yet convinced of its benefits.
The new Web Application Project model is uniquely suitable when:
Only files that are referenced in the project file are part of the project, are displayed in Solution Explorer, and are compiled during a build. Because there is a project file, some scenarios are more easily enabled:
The compilation model for Web application projects is very similar to that in Visual Studio .NET 2003:
All code-behind class files and stand-alone class files in the project are compiled into a single assembly, which is placed in the Bin folder. Because this is a single assembly, you can specify attributes such as assembly name and version, as well as the location of the output assembly.
Certain other applications scenarios are better enabled, such as the Model-View-Controller (MVC) pattern, because they allow stand-alone classes in the project to reference page and user control classes. This is one of the biggest complaints of developers with the WebSite project model - not being able to "find" their UserControls, because of the unique build and environment semantics of the APP_CODE folder.
To run and debug pages, you must build the entire Web project. However, building the entire Web application project is usually very fast, because Visual Studio employs an incremental build model that builds only the files that have changed. I've seen large projects that took upwards of a minute or more under the WebSite model compile in as little as two to three seconds under the new Web Application Project model, so having to recompile whenever you change code should rarely be an issue.
Edit and Continue only works with the built-in development server, but I rarely use it except for quick "demo" projects, so that's of no particular consequence to me.
Because all class files are compiled into a single assembly, only that assembly needs to be deployed, along with the .aspx and .ascx files and other static content files.
In this model, .aspx files are not compiled until they are run in the browser. However, when used with Web Deployment Projects (a downloadable add-in to Visual Studio 2005), the .aspx files can also be compiled and included in a single assembly for deployment.
Each time you deploy the single assembly produced in this model, you replace the code for all pages in the project. This is not only helpful to me, as I've experienced situations where all the precompiled and dynamically compiled assemblies and pages in a WebSite project can get "discombobulated" - causing some real problems, but also, you can drop a "script only" page into your app and it will work just as it did with ASP.NET 1.1 - something you cannot do with a WebSite project -- at least not one that's precompiled - and I don't know about you, but I never could get comfortable with having my "*.cs" files out there on the web server.
I've already converted most of my "stuff" to the Web Application Project model, and in my opinion (YMMV) it's made my work a lot easier - especially site maintenance.
For ASP.NET 2.0 developers who have some trepidation about migrating WebSite model projects, I would encourage you to look at the excellent set of tutorials and information that Guthrie and his team have put together.
There are also some known issues that developers should review. None of them have been problematic for me, but then again, everyone's enterprise environment is different, so it would be wise to review the list. The Web Application Project and templates are included in the Visual Studio 2005 SP1 (Service Pack) which is still in beta, but I use it.
As with most other good things in life, taking some time to RTFM will help you to avoid unnecessary questions later. After all, if somebody drives up with a new Bentley Turbo and hands you the keys, you probably want to sit up in bed and read the owner's manual, right?
However, I see from forum and newsgroup posts that a significant number of developers have obviously either not yet found the Web Application Project add-in, or they aren't yet convinced of its benefits.
The new Web Application Project model is uniquely suitable when:
- You need to migrate large Visual Studio .NET 2003 applications
- You need to control names of output assemblies
- You need stand-alone classes to reference page and user control classes
- You need to build a Web application using multiple Web projects
- You need to add pre-build and post-build steps during compilation
- You, like me, just decided you don't particularly like the WebSite app!
Only files that are referenced in the project file are part of the project, are displayed in Solution Explorer, and are compiled during a build. Because there is a project file, some scenarios are more easily enabled:
- You can subdivide one ASP.NET application into multiple Visual Studio projects.
Omar Khan has put together some really good material on this in a three part "blogathon" which is, in my opinion, first-rate. - You can easily exclude files from the project and from source code-control.
- You get more flexibility and control over what happens when you use the Publish option from Visual Studio.
The compilation model for Web application projects is very similar to that in Visual Studio .NET 2003:
All code-behind class files and stand-alone class files in the project are compiled into a single assembly, which is placed in the Bin folder. Because this is a single assembly, you can specify attributes such as assembly name and version, as well as the location of the output assembly.
Certain other applications scenarios are better enabled, such as the Model-View-Controller (MVC) pattern, because they allow stand-alone classes in the project to reference page and user control classes. This is one of the biggest complaints of developers with the WebSite project model - not being able to "find" their UserControls, because of the unique build and environment semantics of the APP_CODE folder.
To run and debug pages, you must build the entire Web project. However, building the entire Web application project is usually very fast, because Visual Studio employs an incremental build model that builds only the files that have changed. I've seen large projects that took upwards of a minute or more under the WebSite model compile in as little as two to three seconds under the new Web Application Project model, so having to recompile whenever you change code should rarely be an issue.
Edit and Continue only works with the built-in development server, but I rarely use it except for quick "demo" projects, so that's of no particular consequence to me.
Because all class files are compiled into a single assembly, only that assembly needs to be deployed, along with the .aspx and .ascx files and other static content files.
In this model, .aspx files are not compiled until they are run in the browser. However, when used with Web Deployment Projects (a downloadable add-in to Visual Studio 2005), the .aspx files can also be compiled and included in a single assembly for deployment.
Each time you deploy the single assembly produced in this model, you replace the code for all pages in the project. This is not only helpful to me, as I've experienced situations where all the precompiled and dynamically compiled assemblies and pages in a WebSite project can get "discombobulated" - causing some real problems, but also, you can drop a "script only" page into your app and it will work just as it did with ASP.NET 1.1 - something you cannot do with a WebSite project -- at least not one that's precompiled - and I don't know about you, but I never could get comfortable with having my "*.cs" files out there on the web server.
I've already converted most of my "stuff" to the Web Application Project model, and in my opinion (YMMV) it's made my work a lot easier - especially site maintenance.
For ASP.NET 2.0 developers who have some trepidation about migrating WebSite model projects, I would encourage you to look at the excellent set of tutorials and information that Guthrie and his team have put together.
There are also some known issues that developers should review. None of them have been problematic for me, but then again, everyone's enterprise environment is different, so it would be wise to review the list. The Web Application Project and templates are included in the Visual Studio 2005 SP1 (Service Pack) which is still in beta, but I use it.
As with most other good things in life, taking some time to RTFM will help you to avoid unnecessary questions later. After all, if somebody drives up with a new Bentley Turbo and hands you the keys, you probably want to sit up in bed and read the owner's manual, right?
No way jose'. Web Site Model Rocks
ReplyDeleteWhoever says that the website model rocks is a moron! Microsoft should not have come up with that model at all.
ReplyDelete