You might have noticed two types of web-based solutions in Visual Studio- ASP.Net Project and ASP.Net Web Site. Why do we have these two different project types? Which should you prefer? Why would I choose one over the other? I’ll try to answer these questions in this post.
The Major Difference
The biggest difference is that with the model where everything is compiled into a single DLL file, your have complete control over the classes that your application generates. You know where they are and can always reference them from anywhere else in the application.
With the single page model, you can’t do this. You have to get around it by creating “stub” classes in the App_Code directory, and inheriting those in your pages, but even that isn’t ideal, and add complexity.
In other words, a web site creates code behind pages that are compiled at the server when page is requested. A web project creates pre-compiled pages into one or more assemblies (entire site even), and deployed on server. Check the below scenarios: Scenario 1 – If a hacker obtains your code-behind files, any database passwords are exposed. These pages are compiled at the time they are requested. You can choose to pre-compile everything into a large assembly. If not, there is more load on the server.
Scenario 2 – if a hacker obtains your assemblies, they will be obfuscated. Obfuscated assemblies are harder to crack. These assemblies are pre-compiled, thus reducing load on the server.
A website is a site with content that is likely to change over time, that is the pages themselves will change. There is no actual project file and the site is deployed simply as a set of files.
An application is a site where the content is just the application, the dynamic part will mainly be in persistant store such as a database. It will have more complex logic since its likely to represent a set of forms for data entry as much as a means to examine content. It has a project file to more strictly control its configuration and its code deployed as a compiled DLL.
Website Pros and Cons
Web Site lets you treat it like a PHP or classic ASP site, where you can make inline changes that take effect immediately.
- You can make tweaks to the site right on the web server.
- Deploying is as simple as copying the folder.
- If you are not making the changes right on the live site, you can get into change management problems, where you forget to keep all your files in sync.
- You can get runtime syntax errors displayed to your end users, since the only way to check is to manually run every page.
Web Application Pros and Cons
Web Application lets you treat it more like how you would a desktop application – there is one deployable that is compiled on your machine.
- Clear, structured change management. You cannot accidently mix code from two different versions. This can be important when there are 2 people involved – one writing the code, and one responsible for putting files on the server.
- Because you compile it on your machine, everything gets syntax checked at that point
- Deployment is a little more involved then just copying the folder from your development machine. However the usage of the “Publish” command greatly simplifies the process of compiling and putting together what files should be copied to the web server.
- Any changes need to be done on your machine, compiled, and a whole new version sent to the web server.
So, what should you prefer?
If your work needs to leverage to language features (class hierarchies, namespaces) or if you need to reuse common code among projects (data access, class libs etc.) then the web application project is the only way to go.
The website project (the clue is in the name) is only really good for non-complex ‘brochureware’ sites (where the pages consist of static content) as opposed to web applications.
In a briefest summary
Web Sites are used where there is no testing methodology in place, no CI server, and a culture that encourages and promotes fixes to specific pages regularly. Web Applications are in fact standard where proper software methodologies are followed and there is unit testing (if not full TDD) and a CI server with a focus on writing clean code and finding bugs before the need for a hotfix arises.