Few days back I summarized the difference between a project system and a project templates; today I want to focus on key differences between different project systems available for web developers in Visual Studio…
You might be aware of the fact that we have two different types of project systems for Web developers i.e Web Application Projects (WAPs) and Web Site Projects (WSPs)… Often time I get asked this question on which type of project should to use for web development… Sometimes web developers even start a religious war on the two choices, honestly here you have an option to choose the god of your own choice and this post is my attempt to help you make an informed decision…
Most of the time I land up asking questions to people before actually recommending a particular project system. I will try to keep the format of this post in that similar fashion as it typically works out easier to come to a conclusion… If you are in a hurry and do not care of about the inner workings then feel free to just read the questions (in bold) and the highlighted winning project system name in the answer :-)
Q1. Do you intend to deploy source code on your production server and edit it right on the server if there was a time sensitive bug reported ?
If you answered Yes to the above question, you want to use Web Site projects (WSPs)… In case of Web Site projects Visual Studio does not really compile your source code on your dev box, it merely uses aspnet_compiler to validate that your source code will actually compile and run on the server… Hence when you try to deploy a web site people typically also deploy the source code on the server which allows them to edit the source right on the production server if there was a time sensitive bug reported…
Q2. Conversely, are you sensitive about not having your source code openly available on production servers?
If you answered Yes then you want to use Web Application Projects (WAPs)… In case of WAPs the .aspx.cs or .aspx.vb files are actually compiled via VS and converted into a .dll which actually resides in the BIN folder of your project… The generated dll is named as MyProject.dll by default (but you can change the name and also potentially strong name sign it if you care)… Hence in case of WAP projects you do not need to deploy you .aspx.cs or .aspx.vb files which prevents exposure of your source code, in case of WSP you need to deploy these files… The subtlety to note here is that Visual Studio in this case is actually calling C# or VB compilers to compile your .aspx.cs or .aspx.vb files whereas in case of Web Sites the ASP.NET RUNTIME compiler calls the C# and VB compilers internally on production servers...
Q3. Do you care to unit test your source code which is present in your .aspx.vb/.aspx.cs files?
I know this is a politically flaming question, don’t answer it aloud :-)… If you answered Yes then you want to use WAPs… As WAPs generate a DLL out of your .aspx.cs and .aspx.vb files you can very easily create a Unit Test project using MBUnit, NUnit, VS Unit Test etc and add a reference to the WAP DLL… In case of WSPs there is no DLL generated on developer box hence it is difficult to reference that code and write unit tests for them… Not that it is not doable but it is not very intuitive and easy as in case of WAPs…
Also additionally if you have factored your C#/VB source code in a class library and are unit testing that library then WSP projects will work just fine…
Q4. Do you want many developers editing the deployed site as and when required by going to the server ?
If you answered Yes then refer to Q1. the rationale is simple WAP does not give you an option to edit .aspx.cs or .aspx.vb files on the server directly hence you need to use WSP in this case…
Q5. Do you use Source Code Control like VSS or Team Foundation Server to store your sources ?
This question was just for fun and clarity… :-) It does not matter whether you are using WAP or WSP… There is full source code control integration available with both project types so this is not really a deciding factor… Similarly debug, run, view in browser etc all work no matter which project system you choose…
Q6. Do you intend to use Team Build/Cruise Control.NET etc to create a nightly/rolling builds or set up Continuous Integration?
If you answered Yes then ideally you are better off with WAP… WAP is actually a MSBuild based project system and as you may be aware MSBuild is the basis of most command line build/test/deploy model for projects created by Visual Studio... It contains .csproj or .vbproj file which contains all the MSBuild semantics to be able to build/compile/deploy your web project, hence it is very easy to set up command line builds, deployments etc with WAPs. WSPs on the other hand have no .csproj or .vbproj files, we provided rudimentary support for WSP to use command line build using Solution Files (.sln)… It is not rocket science to have WSP projects build in Team Build/CC.NET but the fact is that when WSPs were designed back in VS 2005 continuous integration (CI) was not the primary scenario rather quick easy editing of web pages was a higher priority…
A different way of thinking about this is that there can be a lot of generic MSBuild based plug-ins (tasks/targets) which can out of the box work for WAPs but will need your own manual tweaking around to get them to work with WSP… Essentially this decision point is not as black n white but without doubt WAPs will be way easier when it comes to MSBuild/Team Build support…
Q.7 Do you intend to remotely connect to your web and edit it via FTP?
Many people create their web sites and deploy it to a remote server… Eventually, they want to be able to connect to these LIVE sites from Visual Studio and edit them live by adding more features to them, fixing bugs etc… If you are one of these folks then WSP is a better bet for you as WSP allow you to open a Web Site on the server and edit it right inside of Visual Studio… Again it boils down to the fact that the server actually has your source code so it is possible to edit it via FTP or FPSE and as WAPs do not have source code it does not really make sense to try to edit them…
While we are on this topic, let me mention “please try to avoid using FPSE, it is a deprecated technology on the server side and sooner or later Visual Studio will stop supporting it”…
Q.8 Is there a possibility that you might ever loose your source code from your dev box if your hard disk crashed and you never had source code control back up?
Sounds like a silly question right, but many times for my personal web sites I do land up in this bucket… Recently I lost the source code for a portion of KritZu project, well it was a windows app but the point is that for my tiny home grown projects I sometimes do not have a proper source control repository…
Anyways in this scenario if you had a WSP and had deployed it with source code on the server then you might be better off… But then honestly this is a silly reason, please create back up of your source code somewhere and don’t use this as a differentiating factor… Additionally in VS 2010 you can also create source package of your project and potentially save them somewhere, it makes creating back ups for source code in WAPs much easier, so in case of VS 2010 you can also use WAP equally well for this scenario…
Q.9 Do you intend to update just few .aspx and .aspx.cs/.aspx.vb files and do not want to recompile your project?
If you answered Yes you want to use WSP… Again as described in Q.1, 2, and 4 above Web Site project has source code on the server and it gets compiled there so if you just want to update one file and push it on the server then you do not need to recompile your project. This is the very reason why “Copy Web Site” feature is available only with WSP and not with WAP… In case of WAP as all the .aspx.vb/.aspx.cs files are actually compiled into a DLL if you want to just change one of it you have to recompile….
NOTE: If you just want to change .aspx files and not .aspx.vb/.aspx.cs then WAP is equally good…
Q.10 Do you intend to leverage Web Deployment features of VS 2010 and MsDeploy?
If you answered Yes then you want to use WAPs… There are tons of Web Deployment features available in VS 2010 for WAPs, some of them are:
- Overview of Web Deployment with VS 2010 and IIS
- Web Packaging: Creating a Web Package using VS 2010
- Web Packaging: Creating web packages using MSBuild
- Installing Web Packages using Command Line
- 10 + 20 Reasons why should you create Web Packages
- Web.config Transformation
- DB Deployment with Visual Studio 2010
- Web 1-Click Publish
Not that the above features will be supported in Web Site someday but we initially implemented the entire feature set on MSBuild so that it can be supported in a CI model on CC.NET/Team Build and as it is very straightforward to hook MSBuild WAPs was the de-facto choice… WSPs do not have a project file and hence trying to implement this for WSP will require a major changes in WSPs which we are not able to accommodate within VS 2010 box…
Q.11 Have you heard of Web Deployment Projects for VS 2005 and VS 2008?
Web Deployment Projects (WDP) are an add on to VS 2005 (Download WDP 2005)and VS 2008 (Download WDP 2008)… WDP is a MSBuild based project and it has its own project file… It essentially takes the output of WAP or WSP and pre-compiles/merges it into DLLs which are ready to be deployed… Essentially WDP does the compilation that ASP.NET Compiler would do at RUNTIME and so if you use them during build time then your web pages’ FIRST TIME load performance will significantly improve (as ASP.NET will not have to compile the pages on the server)…
For WSP this means that you get some of MSBuild benefits of integration with Team Build/CC.NET but then you loose the flexibility of having your source code on the server and editing it anytime you want… In any case WDP in my opinion should NOT be one of the deciding points while choosing WAP or WSP, in fact WDP works just fine with both the project systems…
Many people try to use WDP to get Team Build style benefits on WSPs but then I would recommend pausing and asking yourself a question “Why are you using WSP if you are about to loose many of the advantages of WSP like being able to edit code files anytime, etc?
So from WDP standpoint either WAP or WSP is equally ok…
Q.12. Do you write inline C# or VB code in .aspx files (in addition to / instead of writing it in .aspx.cs or .aspx.vb)?
People sometimes do write <script runat=”server”> int i;</script> or <%= %> style code inside the .aspx pages… If you do so you should note that WSP provide better intellisense and refactoring here… But most of the times the difference is not very noticeable in WAPs either (at least not many people are screaming about it :-))… So if you leave that part alone both WAP or WSP work the same from this standpoint…
The code written in .aspx pages EVEN IN CASE OF WAP does not get compiled by VS… The code in .aspx pages is left as is and is compiled by ASP.NET compiler on the server… So essentially even if you are using WAPs you can also edit the code written in .aspx on the production server… Certainly, you can do this with WSP too…
So when it comes to writing inline C# & VB code WSP and WAPs are more or less the same…
Q.13 Do you aspire to write both VB and C# code in a single Web Project?
What if people who love VB could write VB code and people who love C# could write C# code and they both can work on the same project at the same time… Interesting idea right…? You can imagine that in some community project people may decide to do this… In enterprises or formal companies I have never seen this happen due to maintainability reasons… Anyways, even for kicks if you want to write both VB and C# code in the same Web Project it is way more simpler to do so in WSP than in WAP…
Again it is not impossible to do it in WAPs but slightly more convoluted… The reason why it is complicated to do this in WAP is coz WAP compiles everything based on the project file which is either vbproj or csproj… WSP on the other hand is just a folder and ASP.NET RUNTIME can call any compiler based on the file extension… There are some ifs and buts and maybe someday I will write about them but for now WSP is more preferred in this scenario…
Q.14 Have you heard of ASP.NET MVC projects?
In my Project template vs. Project system post I had mentioned that ASP.NET MVC Projects are a type of WAP… To further explain it MVC Projects are essentially what we call as “Flavor” of WAP… Flavor is a special little “lingo” of VS :-) think of it as a special type of inheritance i.e. MVC Projects flavor WAP Projects who in turn flavor Class Library projects and all along the line you keep getting more an more features while the child projects can hide features of the parent as well… For e.g. MVC projects hide “View in Browser” command while adding “Add a View” command…We can talk more about this some other time but in nutshell MVC projects have got controllers and model classes which all get compiled into DLLs and the Views get deployed as they are on to the server…
MVC projects also are pro on Unit Testing so in lines with Q3. we just decided to avoid any confusion and just created MVC projects for WAPs… So if you are using ASP.NET MVC you are most likely using WAPs… Again using ASP.NET MVC with WSP is possible, it is just not straightforward option and some IDE features may not be available out of the box if you were using MVC with WSP today…
Q.15 Do you want to edit your code while debugging (w/o stopping debugging)?
Edit & Continue feature is supported only in WAP projects and not WSP hence if you care about Edit & Continue then WAP is your option of choice…
In conclusion, there are more subtle things to look out for… e.g. Few days back I explained why App_Code does not work all that well with WAPs… But other things should be hopefully minor issues and the above decision points should hopefully allow you to make an informed decision when WAP vs WS discussion comes up again…:-)
There are more subtle differences between WAP and WSPs and some of them are discussed in the white paper on MSDN…
Hope this discussion helps and do not hesitate to reach out if you would like to know anything in more details…
-Vishal
