Web site vs web application in Visual Studio
- 📅
- 📝 405 words
- 🕙 2 minutes
- 📦 .NET
- 🏷️ Visual Studio
- 💬 12 responses
Rob Conery got me thinking about web site maintenance and I put forward a brief comment on the two distinct types and how Visual Studio handles them which I have expanded upon here.
Web site
Primarily for working with ad-hoc web sites that have programmed elements. Easily identified by customer-specific content present in aspx files.
No solution or project files are required and the pages and source can reside locally (file system, IIS) or remotely (FTP, WebDev/FrontPage extensions) via the File > Open > Web Site… menu option.
Code-behind and classes are typically stored on the web server which compiles them in-memory on demand. Changes can be made to the files without restarting the application and losing sessions.
| For | Against |
|---|---|
| Quick edit, test, deploy cycle | Syntax errors at run-time |
| No need to compile or restart app | Can’t create an installer |
| Source always available | Source on server useful to hackers |
Web application
Web application projects were introduced as an add-on for Visual Studio 2005, later rolled in to VS 2005 SP1 and made a full first-class citizen with Visual Studio 2008.
Like the name implies these are primarily for web applications, those times when you have written a product or solution that happens to have a web interface.
Web application projects exist on your local drive and are treated like any other VS project type and can be added to existing solutions are subject to full compilation, validation and build steps.
Deployment is typically via MSI installers however you can also utilize the addition Web Deployment Projects add-in which allows you to deployment directly to servers which is useful for deploying to test environments.
| For | Against |
|---|---|
| Controlled build & deploy process | Deployment causes application restart |
| No class files on web server, dll only | Can’t deploy individual classes |
| Syntax errors at compile time |
Hybrid
Sander and I were discussing this article and thought an interesting solution might be to use the Web Application model for local development but to use the Publish option to publish all solution files to an intermediate directory.
Then in the intermediate directory just remove the bin/applicationname.dll file and copy to the target. This should prevent an application restart unless the web.config or global.asax/global.asax.vb files have been modified.
[)amien
12 responses to Web site vs web application in Visual Studio
“Codebehind” refers to the code associated with an aspx page. I guess you could broaden that to all the code in all classes, but I really think it was meant to be more limited. The additional classes are still called “components”.
As for Bruce’s comment that the web app method is dependent on good working practices, most of those bugs can be caught in local testing. Once in a while, someone forgets to upload a DLL, and then yes, that only happens with web apps and not web sites.
Here’s a few additional thoughts on both deployment methods:
Website Method — Con: Very prone to failure due to outside influences. For example, Indexing Server locking the temp dll files which then causes sync issues.
Web Application Method — Con: Totally dependant on good working practices. It only takes one junior developer failing to use Sourcesafe correctly to take down the whole site rather than just a single page. This is obviously more relevant to smaller development teams. I work in a small team and I’ve seen it happen more than once :)
@Lucas: I intended on writing something about VS2003 only to find I couldn’t remember much about it apart from hacking Class Library projects to behave as a web site you could store locally.
Thanks for the kind words!
Oh, and another thing… I enjoy you blog very much. Keep it up ;)
Hi Damien,
Just wanted to clarify, you make it seem like “web applications” projects were developed after “web sites”. As I remember it, web application was the only way in VS2003, and was replaced by web sites in VS2005. I think enough people missed web apps so much that it was released as an add-on to VS2005, included in VS2005 SP1, and later in VS2008.
I realise you said “classes are typically stored on the web server”, but just thought I’d clarify that you don’t have to deploy the source with Web Site. There are a number of publishing/precompilation options for Web Sites to avoid having to do this. Regards, David
We had a ‘semi-continous’ integration server setup, in that the codebase was continuously rebuilt and unit tests run against it, but deployment was a separate step. Most CI servers don’t operate within the same environment as the ‘real’ sized production / system test environs so can’t 100% recreate it, unless it’s very simple or your CI setup has a chunky budget (unlikely if you already have to fund full-size acceptance test environments, unless you’re loaded). Stuff like integration with external systems, full-scale tests and even some aspects of web testing can’t be done entirely properly by a CI setup, which is usually running on a modest dev box. We also had a strict sign-off system where it shouldn’t be possible for a dev to deploy anything to a production server, only ops had that access and they required sign-off from acceptance testers (business stakeholders) first. We had scripts that did the deployment from any release to any server so it was repeatable no matter who was doing it, but we didn’t find a decent way of integrating that into a CI setup.
@Steve: Yes, there wasn’t a need for a new term. Just saying the code was in a class should have been enough to understand it wasn’t inline script.
@Baggio: Sorted! I’ll get there eventually ;-)
@Ken: That seems like a nice balance. Do you automate the deployment steps with scripts?
Personally I’d love my web sites and apps to be deployed from a CI server on demand but we’re still some way from continuous integration here.
My favorite schema — I use MonoRail and AspView. So to the server I only deploy:
so, usually a fix process to a template is: a. run vcompile (created CompiledViews.dll out of the view templates) b. copy compiledViews.dll to deployment machine.
@Damien: loosing sessions ? :)
Before you ask, yes ‘servlet’ annoys me just as much. I mean, it’s not even a proper word. shakes fist
‘Code-behind’ is one of those terms that irrationally annoys me, because it’s another term we didn’t need. There were perfectly good terms already (like ‘component’ perhaps) to represent having compiled code behind a web application — after all in the days of yore ALL code was compiled (CGI), on-demand server-side code came later. I used DLLs behind a pre-.Net ASP application 10 years ago, written in VB6, and I didn’t feel I needed a new term to describe it. Tsk.