Saturday, August 08, 2009

Web Application Project Vs Web Site

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 WSPAgain 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:

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

95 comments:

Anonymous said...

I just can't help but thinking most of the WSP reasons are also indicators of sloppy development practices.

Sebastien Lambla said...

In other words, if you're not a software development professional, don't care about current development practices, you're fine with WSPs.

Ah if I could make sure every person that replies to one of those "are you not taking reasonable care when developing" with a yes had their name on a list, it'd make my recruitment so much easier.

Anonymous said...

I'm also pretty sure that if you're doing Silverlight development in a TFS/Team Build scenario, the xap files will not automatically get copied into the ClientBin folder if you choose WSP.

Vishal R Joshi said...

>>I just can't help but thinking most of the WSP reasons are also indicators of sloppy development practices
Vishal: Well in all honesty there are specific cases where people need to do on server development like on dedicated hostings where things are build built by a very few people...

Sheron said...

Another reason to go for WAP is if you wish to have sub-web projects in Visual Studio. Checkout this blog post by Scott Gu for more info - http://bit.ly/2WCkNb

The sub-web projects are used by us to separate our user-facing web site and its admin console into two distinct web apps on publishing. The admin console is then deployed on a server which is accessible only from the internal network. Needless to say, both the user-facing site and the admin console use the same database.

Vishal R Joshi said...

Erick had a great question
>>>> how does source control impact the decision, and what about designers using expression studio, or some other ASPX aware editor?

Vishal: When you are working with someone who is also opening the same project as you are then as WSP is simply a folder (no project file) it can very easily open in any other HTML editors... WAPs have a project file so not every editor will be able to open the projects... If you live inside VS then perhaps this is not a big deal at all I guess...
As far as the source code control is concerned in case of WSP everything is just a folder and that is what you check in... In WAP you check in the project file too... Your team mates in either case should be able to get your project and work on it...

There is one other point which I remembered is worth mentioning... If you customize the project settings in WSP (e.g. start up page, Cassini settings etc) it is stored in a common XML file called WebSiteCache this typically will not go to source code control so the customization for WSP remains on the particular machine (except if you manually port the WebSiteCache settings)... In case of WAPs all these customizations go into the project file hence they can easily move to source code control...
-Vishal

Chris said...

Great article, very informative.

Anonymous said...

This article has now become my standard reference to answer the question of WSP vs. WAP.

My only quibble is that I don't know of any other kind of "project" in Visual Studio that does not have a project file of some kind. In that light, I've taken to saying "web sites are not projects". But now that this article calls them "Web Site Projects", I guess I'll have to do the same. :-)

Vishal R Joshi said...

Thanks Chris & Jacks...

Vishal R Joshi said...

>> John Saunders about Web sites being a project

What is in the name :-) "Web Sites" or "Web Site Projects" all are fair name... It is worth noting that Web Site project system has got 100s of thousands of line of code to deal with that "folder without project file" and probably takes equal attention of the team as WAPs...!!
-Vishal

M Shasur said...

Great Blog Vishal! This particular post makes a good reference for selecting the correct project option in VS

Anonymous said...

> I just can't help but thinking most of the
> WSP reasons are also indicators of sloppy
> development practices.

> In other words, if you're not a software
> development professional, don't care about
> current development practices, you're fine
> with WSPs.

Mixing markup and code is the real sloppy practice, and that's what WAP promotes, to put everything in one project (even the DAL).

Just because you can do bad things with websites doesn't mean you have to. Furthermore, it practically forces you to have at least an additional project for your DAL/BLL.

Anonymous said...

There are times when a WSP makes sense. Example: when you have to put a site up in reaction to an urgent situation and be able to change it quickly.

Jags said...

I am using WSP for almost all of my applications and i don't see source files(i mean .cs files on production server). There are dll for each and every .cs file. Could you please let me know if i need to change any settings or something?? Thanks.

Vishal R Joshi said...

Jags, if you use "Publis WebSite" feature or WDP with your web site then you are actually pre-compiling your web in DLLs before pushing them to the server... In that case there is no need to push source code to the server...
-Vishal

Andrew said...

How do I convert a WAP to a WSP?

Unknown said...
This comment has been removed by the author.
Unknown said...

Thanks for this post, it clarified that topic for me.

Nizar Noorani said...

Very informative. Thanks!

Anonymous said...

Thank you following my site..... http://itsolusenz.com

Anonymous said...

I think you missed a VERY important point.
If you do the BAD mistake of using WSP for a website that will become bigger and bigger during the years, you will find yourself with an unmanageable amount of pages and to start a simple debug session you will wait 20 minutes (and 20 minutes to compile it and merge it too)!
I think more than 2 months of my development times in the past 2 years have been lost for this bad decision (grrr).
Now I managed to completely restructure it for WAP and I can go into debug in 3-4 minutes.
I feel this is also MS fault for pushing this WDP as the standard way (when I started the project WAP wasn't available) and then releasing patches for using WAP.
It should be as simple as this:
Amateur small site or test site = WSP
Anything professional = WAP

Source: hard learned experience.

abcplex said...

How to use alias for assemblies (which is avilable in WAP) in WSP.
I have asked here, but not found answer.
http://forums.asp.net/p/1447176/3294018.aspx

rtpHarry said...

Interesting post, enjoying reading it so far - just read q3 and think you have made a typo?

"Not that it is not doable but it is not very intuitive and easy as in case of WAPs…"

shouldn't it be "is doable"?

rtpHarry said...

Ok I have read it all the way though and the accompanying app_code article and from these it does kind of hint that if you use a WSP you are probably doing it because you are a hobbyist developer.

I started out using the free VWD and therefore most of my website are website projects. I never had a good reason until recently to have full solutions and project combo's setup (the good reason was massive project which has admin and multiple front ends and supporting libraries). I just made a folder in app_code for my layers and went about my day.

Anonymous said...

"Jags, if you use "Publis WebSite" feature or WDP with your web site then you are actually pre-compiling your web in DLLs before pushing them to the server... In that case there is no need to push source code to the server..."

so does that mean Q2 is also a draw??

Anonymous said...

Great article, thanks! From what you have described for the most part the main differences relate to compilation, deployment and maintenance considerations and I can see how one would be better than the other if certain conditions.
However, from my understanding, WSP was introduced by Microsoft to make it more attractive to web site developers not familiar with the traditional application project model most VS developers were comfortable with. It was almost a, dare I say it, marketing ploy to widen acceptance of Visual Studio as a development IDE for web developers. I could be wrong though.
Personally, I prefer to WAP to WSP. That’s not to say that one is better than the other, it’s just what I prefer. What does bother me though about having two different project templates is the lack of consistency between the two.
I continually get frustrated that version after version Microsoft continues to leave out Profile class from WAP. Why do I need to create my own ProfileCommon class just because I used WAP over WSP? Is it a huge deal, probably not, but the point is I have to take this into consideration and write additional code that I would not have to if I had used WSP. The point is, I shouldn’t have to think about the impact of moving between the two project templates, they should be the same.

Tyler J said...

I am a firm believer in Web Applications myself, and find that experienced Visual Studio Developers new to Web based programming tend to begin a Web based project with the "Web Site" simply because the option is much more accessible to them via the Visual Studio IDE. I would like Microsoft to remove the Web Site capabilities altogether. When working with a group of other developers, it's nice to have a standard like, "Always create a Web Application." The problem is that the standard doesn't really make sense to someone who has never gone through the pain of converting a large "Web Site" to multiple "Web Application" projects (IE Web with Web Service), or the pain of scaling a System without namespaces to differentiate the class libraries. Therefore, I stand by my opinion that Microsoft should remove the Web Site capabilities all together (Leave it to the Expression products) and give us an accessible "New Web Application" option in it's place, along with it's consistent project and solution structure.

Anonymous said...

This is a great explanation and verry clear.
Thank you.

Anonymous said...

Thank you.. this was really great information and the formatting was very efficient...

Bassem :)

Anonymous said...

Hmm, it seems like a lot of your reasons are that you have to deploy source code with website projects and you do not with web applications. This is actually wrong because you can choose to deploy with or without live source code using both WAPs and WSPs (though it is harder to make your source editable for immediate use using WAPs).

Anonymous said...

In addition, it comes across as an article trying to convince people to use WAPs instead of WSPs because you fail to mention some of the WSP advantages like the fact that you do not have to REdeclare your controls in the codebehind in order to use them (in WSPs).

Anonymous said...

I use WSP and the author is wrong that you have to post source code to the production server. I compile all files locally and then copy the compiled code only to the server. Just use the asp compiler; and you can even use it from the command line. Most of the reasons the author mentions relate to editing files directly on the server. Few people do that. Why? Because you will still need to modify your local code, if you want local and server copies to be in sync. In any case, most people are smart enough to modify local copy of code and then update the server (compiled or not).

So, with WSP you CAN upload source code OR compiled code, it is your choice. Based on what the author says, WAP does not offer you that choice.

Anonymous said...

Vishal,

Im a Newbie with VSTS. We are learning on the fly. I know there is a ton of documentation out there, but most of it is random and haphazard. We use VSTS 2008 and have a bunch of websites and windows service(Solution contains class lib,console app :), windows service). If its not asking too much, could you post the Build steps to build and deploy the website(Deploy everything except the web.config file) and the windows service deployment. I searched your blog and didnt see a post from you on it. Thanks Again Vishal, you rock !

Arvind Ramanathan

Anonymous said...

"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)…"

This is just flat-out WRONG! You can fix a time sensitive bug in a WAP on a production box. Just change the Page directive's CodeBehind attribute to CodeFile to allow for this page/usercontrol to no rely on the project's dll and put the code file on the box with your immediate fix (may not be the final bug fix, but a temporary one to give you time).

One thing I did not see in the post is performance differences. So, I'll give my 3 1/2 cents.. WAPs are just much more efficient and faster than WSPs, since all code is already compiled. Don't need an additional step to compile, as is done in WSPs.

Anonymous said...

It is really nice & informative blog. but.... i still one doubt. Incase i plan to go for a distributed approach for my web application development using VS2K5, i.e. Presentation layer in one project, Business logic in another project, Data access layer in another project... & soon. so which approach should i choose... WSP or WAP?

Many Thanks

Anonymous said...

Gr8. one doubt......
what approach should be taken if need to go for multiple project handling various layers of web development in VS 2005, like Presentation, Business layer, Data Access Layer & so on. WAP or WSP.

PapillonUK said...

Vishal - To be honest, it seems to be 90% in favour of WAP. What do you honestly recommend!!! (I hate these balance debates - I just wish the "experts" would say what they think! i.e. what do YOU use Vish? ;-)

Unknown said...

Hi Vishal, good article but is not totally complete/correct, WebSite Projects CAN be compiled into one (or many) dll files (one per project or one per aspx file if you want), you just need to do it from the command line, in other words, you have the option to deploy the source code to the server ( bad practice but very handy for small "home made" websites ) and you also have the option to deploy just the .dll as in a WAP... so why limiting my options with WAP ?
So far the only reason I see that could make me change my mind to use WAP is the new deployment features in VS 2010.

Anonymous said...

Vishal, Nice post, I am working on WAP (inherits from previous developer) but the client wants to deploy it as WSP as the project become so big and they dont want compile as a whole, So I create .aspx page with codefile (manually change codebehind) and deploy the .vb files along with aspx pages. I guess i can re-create project as WSP and not worried about changing codebehind but I like the WAP because it sounds more technical than WSP. :)

Or should I just do WSP for the new projects?

Unknown said...

Great resource, thanks for sharing....
web application
enterprise application
desktop application
Application Maintenance services

Vishal R Joshi said...

Guillermo, Yes indeed you are correct, with WSP you can use Web Deployment Projects or aspnet compiler/merge tools to pre-compile the site...

Anonymous said...

Hi guys.

Back to WSP vs. WAP.

I definitely want to be able to make frequent changes/improvements to my exiting code as well as add new features/programs to my application.

So it sounds as if WSP is the way to go - since I have many users from different business environments using different modules in the application - and I thus cannot halt the entire application each time I twiddle with something.

However in VS2010 basically everything revolves around WAP.

So my question is: Would it make sense to rather go with WAP, but then to create multiple projects in the solution (almost like keeping each module/program in the application in a separate project). This way you might only have to halt the project on which you are working?
Or doesn't that make sense, since the entire solution will in anyway have to be recompiled after working on any of its projects?

Regards
Gerhard

Vishal R Joshi said...

Hi Gerhard,
If you are using MVC then probably WAP is the default choice but with Web Deployment Projects (WDP) release for VS 2010 a lot of WAP deployment features are getting ported to Web Site Projects too... Try http://blogs.msdn.com/b/webdevtools/archive/2010/05/26/visual-studio-2010-web-deployment-projects-rtw-available-now.aspx...
Overall I would recommend sticking with one model or the other mixing them up will not harm but will just create maintainence difficulties...
Hope that answers some of your questions...
Thanks
Vishal

Anonymous said...

Hi Vishal,

With WAP: do ALL the users first have to log off before you can deploy, or can you deploy individual projects while some users are still working on other projects in the application?

Regards
Gerhard

Vishal R Joshi said...

Hi Gerhard,
You can deploy individual Web Application Projects (WAPs) although this is less of an artifact of WAP and more of how is the uptime you are expecting for your site in IIS... Feel free to send me an email at Vishal.Joshi@Microsoft.com with your specific case study and we can dive more but each WAP deployment is in a way independent of each other...
Thanks
Vishal

Vishal R Joshi said...

>>>> abcplex said...
How to use alias for assemblies (which is avilable in WAP) in WSP.
I have asked here, but not found answer.
http://forums.asp.net/p/1447176/3294018.aspx
[Vishal]: abcplex, Unfortunately there is no way to save the alias information in Web Site Project... :-(
-Vishal

foreign direct investment said...

in my personal opinion i prefert the web site cause is what give the look to the page i really enjoy more of the web that to the project .

Anonymous said...

1. Let's say I choose WSP, and I want to make a change to a .CS file directly in production. Does that trash all my users' Sessions when I make the code change?

2. What if I use WSP but use the Publish method to get my DLLs up to the production server. Then I need to make a bug fix, so I publish again. Do user Sessions get trashed when I re-publish?

Vishal R Joshi said...

I confirmed with Stefan who is guru on our team on this stuff and the answers are:

For (1) the compilation system just recompiles the affected .aspx page associated with the code-behind. So no – the appdomain doesn’t get bounced which means the Session will remain as is...

For (2) yes the appdomain gets bounced because /bin is being touched due to new DLL and thus the Session will get trashed...
Thanks
Vishal

Anonymous said...

wsp doesn't let you to edit the automatically generated codebehind, so you're very constrained in your development by "default" features.

Vishal R Joshi said...

WSP do allow you to modify code beside files i.e. aspx.cs or aspx.vb files... You ideally should not face any issues with that...
Thx
Vishal

michaelvk said...
This comment has been removed by the author.
Sam Stephens said...

Another point, and one that might be worth adding into the article if you are still updating it.
Code Analysis is annoying to use with WSP. Any settings for the project are stored in a file in user profile, meaning that the settings cannot easily be version controlled.
So if you want to use Code Analysis, use WAP.

Anonymous said...

Thank you - finally - a clear explanation. One question - with WAP is it more efficient in resources because of the DLLs or is it a wash if you use MVC?

Vishal R Joshi said...

with WAP is it more efficient in resources because of the DLLs or is it a wash if you use MVC?
MVC Project templates are internally WAPs anyways so there is not really much difference from pure compilation model stand point... In case of WAP the code behind is compiled into a DLL in case of MVC the models and controllers are... Hope that answers your question...

E-Devinci said...

Q5 - incorrect. IF you use TFS then never use WSP as it would be a complete waste. You cannot handle nightly builds (as a website won't build). and Code analysis won't run either.

Honestly - unless you are truly just building a "website" (meaning mostly static pages without complex business logic) - always use a web application.

Unknown said...

I think perhaps the response to Q13 was premature - as far as I can tell it is NOT possible to mix c# and vb.net in a Web Application Project.

In OUR case this simply comes as a result of migrating mixed code that was living happily side-by-side in an asp.net WEBSITE to the Web Application Project

Frank said...

One difference I haven't found discussed yet is that in a WSP you can't set the target CPU of the build other than AnyCPU.
At least from within the VS IDE 2005, 2008 with VB.NET.
Not with Publish Website nor WDP nor anywhere else.
In a WAP you have a Build tab via the project properties with an
Extended Compile Options button where you can choose the target CPU as AnyCPU, x86, x64.
How can I build an assembly specific for x86 from a WSP under these circumstances?

Tax Attorney said...

Great post. I’m thinking that’s the best one….

Vishal R Joshi said...

Hi Frank,
I am assuming you are referring to your code in App_Code folder.. If you have a bunch of code which really matters to be x86 vs x64 compiled then the best way would be to use class library and set the correct compilation mode there then reference the class library from your WSP...
Thanks
Vishal

PS: If this does not work please drop me a line at Vishal.Joshi@Microsoft.com and we can discuss more

Frank said...

Hi Vishal,
Thanks for the tip with the class library.
It's clearly a good solution for the code
in App_Code. But I mean the whole build
of a WSP, that is also the compiled code
of the code behind an aspx file (@Page directive
CodeFile=...)
I know of two menus in the VS 2005 or 2008 IDE
to compile a WSP to dlls: Publish Website and
the Web Deployment project. Neither allows to
set x86, x64 as target CPU. It's automatically
and always AnyCPU.
You need to set up the web project as WAP to
have this feature. That was the point I wanted
to make about the difference between WAP and WSP.
And I was wondering whether there is another
way to compile a WSP to x86 dlls which I
may have missed.

Anonymous said...

Indeed a religious type of a discussion here. Saying that WSP is for sloppy coders is just plain ridiculous. Just because flexibility is offered doesn't make it for amateur. It's wields more power in the hands of experts. I've done both WAP (for over 4 years) and WSP (for 5 years) and I've come to appreciate WSP much better. All you guys out there saying WAP is better for enterprise development, I can already see what your solution file looks like - countless sub projects bound to many virtual directories with post build scripts that copy stuff from child to parent. Even during debugging, having to rebuild or rerun the build script to get the sub folders copied up properly. So, let's not throw stones - you live in a glass house full of many cracks.

Vishal R Joshi said...

Frank,
My assumption is that your WSP code files are managed code and it is always “Any CPU” as it is compiled to IL… The x86 vs x64 should not make much difference. Can you share some more details on why you want to compile code files of WSP for specific CPU target?
thanks
Vishal

Frank said...

Hi Vishal,
Thanks for your interest. Why would I compile a WSP to x86 dll?
Admittedly slightly theoretically, I think of all cases when the
WSP refers to sub-systems like Jet OLEDB 4.0 or Crystal Reports
runtime, and on an x64 production server they're only available
in 32 bit, so the WSP must also run in 32 bit.

I've worked both with WAPs and WSPs for the last years
and would gladly avoid to convert a WSP to WAP
just for the one reason that I have to compile it to x86 dlls.
That's why I asked for an x86 compile option in WSPs.

Vishal R Joshi said...

Hi Frank,
My understanding is that the only assemblies that need to be marked as x86 vs x64 are dual mode assemblies that contain both managed and native code (typically produced by VC++). If your code is making calls to COM components using PInvoke or Runtime Callable Wrapper (RCW), so I am having difficulty in understanding the case... Have you tried a simple WSP making such a calls compiled using WDP to verify whether you are facing any issues?
Thanks
Vishal

Unknown said...

Thanks for this, Vishal. This article has answered a few questions of mine. I'm actually an aspiring web developer here in Canada. There are several Toronto web developers that I look up to, and they've been helping me with the current website I'm putting up. I'm gonna share this to them. Thanks again.

KalC said...

Hi Vishal,

Great article and it helped me convince my boss that for our new environment (we are switching from desktop to web apps) we should go with WAP rather than WSP.

However I am still confused about one thing. Where exactly do I put this DLL for my web application?

Allow me explain the question a little bit... I have a web application project called SampleProject. After I built the project, I have a .dll file called SampleProject.dll inside the bin folder like how you mentioned in your entry. I am writing this application to be deployed on a server running IIS 7.0 on Windows Server 2008. The primary motivation for going with the Web App model is modularity but we also want to hide the source code. In Q2 you said, "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… " ... How exactly do I achieve this? I created a Web Deployment Project to created a SmapleProject.msi and Setup.exe file. But when I executed this setup wizard on my server, the source code is visible entirely. If I only put the .dll file in a folder and create a virtual directory, I get a 404 error.

I know this is sort of a newbie question, but need to get a clarification. Thanks.

Vishal R Joshi said...

Hi KalC,
I might be overloading you with information but take a look at http://vishaljoshi.blogspot.com/2009/09/overview-post-for-web-deployment-in-vs.html... It talks all about deploying Web Application Projects.
The short answer to your question is try right clicking your Web project and select Publish... Then choose file system and provide a local folder like C:\Test to publish the project. Now whatever is copied to the C:\Test folder is what needs to go into the IIS 7/Win2k8 box... Although sometimes it is more than that so please do check the blogpost and videos above.
Thanks
Vishal

Kalyan said...

Thanks Vishal. Lots of useful material there. Really appreciate the quick response.

Kalyan

careprost said...

you are really doing great work, I would like to join your blog

Loan Modification said...

Substantially, the article is in reality the sweetest on this precious topic. I harmonise with your conclusions and will thirstily look forward to your upcoming updates. Saying thanks will not just be sufficient, for the phenomenal clarity in your writing. I will directly grab your rss feed to stay abreast of any updates. Pleasant work and much success in your business efforts!

Anonymous said...

http://www.techbubbles.com/aspnet/aspnet-website-vs-web-application-project/
THIS IS RIGHT ONE...

Anonymous said...

i choose website because when you're dating, and your angry boss tells you to add a new feature right that minute, you would wish your project is a website and not web application.

the hell with web application. website project does not equate to sloppy development.

"you can reference another page functions with web application" - Now that's what I call sloppy !

Levi Fleischman said...

"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"

I love that you provide an objective comparison of the two formats, and yet the zealots still interpret it as dogma.

I work for a professional software development company, and we use WSPs for a surprising number projects. In many cases, this is because our clients (often large, enterprise customers) don't permit compiled code on their web servers. Other times it's because we have very large, content-oriented websites that can't be broken down cleanly into separate projects, but are being edited by dozens of people using a variety of editors.

This doesn't change how we architect the code one bit. Nor does it make the output any less professional.

In fact, more often than not, we end up with website projects alongside several external class library projects for handling the data access layer, caching repository, server controls, web services, page classes, Visual Studio templates, etc. In MY opinion, more often than not, if you're writing a TRULY professional web application then most of your code shouldn't even be tied to your website - at least, not on a page by page basis!

In fact, for that reason, we will even use inline code much of the time. The reason being that our "code behind" is almost never more than 5-10 lines of code and is more akin to scripting than development; the vast majority of our sites are built declaratively by production staff, with the heavy lifting being handled by centralized code via web services and/or declarative controls.

That isn't to say that we don't use the Web Application project template. We frequently use this for self-contained applications, such as administrative tools. But this is a decision we make on a case-by-case basis, depending on the project. The irony, in context of this discussion, is that we often use the WAP when we don't have the time or budget to write the application according to our normal techniques!

This isn't to say that the Website project is better than the Web Application project. It really depends on your project, how you're architecting it, who is maintaining it and how you're publishing it. I completely agree that, out-of-the-box, the WAP encourages a more professional result. But it's simply naive to say that only amateurs use the website project and that professionals use the WAP.

Sarah conoway said...

Website all the way, forget applications. My 2 cent.

insanity said...

What I want to know is why you didnt think to include the other side of this issue? There are so many things that youre missing here that I dont see how you could actually form an intelligent opinion on the subject. Its like you didnt even consider that there me be another side here. Im kind of disappointed.

paycheck loan said...

I admire the way you express yourself through writing. Your post is such a refreshing one to read. This is such an interesting and informative article to share with others. Keep up the good work and more power. Thanks!

Xavi said...

Nice blogg!!
Keep doing!

Anonymous said...

We have created our own "Flavor: its a WSAP. It takes the best of both of them. I do automated nightly builds, I use the AppCode folder for separated BLL and DAL. I have "modular projects" with different developers all checking into a SourcSafe repo..it works well for us, I think that is tha bottom line, what works well for you and your team. It may take time to figure it out and you may not be able to use all the "cool" MS stuff, but really at the end of the day, you need to get the job done!

Nauka jazdy bielsko-biala said...

This isn't to say that the Website project is better than the Web Application project.

OSK Bielsko Biala said...

This isn't to say that the Website project is better than the Web Application project.

Sunburn Treatment said...

thanks for differentiating between the two!!

web design company said...

The differences u have made are simply amazing and quite interesting.Thanks a lot for making the best points on the web application and a website.Cheers !

Anonymous said...

Very helpful ... thanks!

Anonymous said...

The points are clearly mentioned. Its very helpful.. Thank you...

Kenny Carter said...

Maybe I will choose web application project because for me, different web applications such as site builder or creator makes the "web site".

Anonymous said...

hi Vishal
note on differences between web application and web sites is very good, it helped me lot.
Thank you .

Anonymous said...

There is no difference in performance between a Web site project and a Web application project. The only significant exceptions are the ones that have already been noted, and as a practical matter they apply only to very large sites. The first request to the Web site might require the site to be compiled, which can result in a delay. And if the Web site is running on an IIS server that is short on memory, including the entire site in a single assembly might use more memory than would be required for multiple assemblies.

SOURCE: http://msdn.microsoft.com/en-us/library/dd547590.aspx

Pay Per Click ROI said...

Nice post, but please use PNG for your screenshots in the future.

Mohammad said...

Hi Vishal
so mvc projects are WAP, we cant just use XCopy to host it on iis!
cool, however yesterday i published my mvc2 application using clickonce (which from your post and comments i understood that it pre-compile everything) to a remote server, and yet i can still see my files (uncompiled) infact i was able to open my c# classes using notepad! how is this possible?
Thanks

Unknown said...

Thanks for the article .I was looking for this comparison.

Anonymous said...

I know I'm late to the party here, but I take issue with Q15. We choose WSP specifically so we CAN alter code while debugging. We place the BLL and DAL in the App_Code folder. When these items change, we do have to recompile. However, mostly we build these out in the beginning and rarely touch them. Much more often we are editing the aspx page and the code behind (.cs) page at the same time. With WSP, I can not only change code variables (both during a pause AND during postbacks), but I can also add new controls to the aspx page and write code referencing them in code behind, and all I have to do is click refresh on the browser to see my changes. This is something you cannot do in WAP, no matter what your settings. Development time is much shorter with WSP for us, precisely for this reason. And full disclosure, we make custom financial software for clients and our projects are never on the order of thousands of pages. If so, I might have a different experience...

Anonymous said...

sorry, that should have said "BETWEEN postbacks", not "DURING postbacks"...

Amy said...

So in the scheme of things, is VS 2012 Express for Web better to use than Expression Web4 for creating a web application? I am trying to create a web app that will run from a cloud. Which should I use?

Anonymous said...

Awesome ... very informative thanks so much