This question already has answers here:
ASP.NET Web Site or ASP.NET Web Application?
(25 answers)
Closed 3 years ago.
When creating a new ASP.NET project in Visual Studio should I chose create: website or project?
I understand that web application project was the way to do it back in the day with VS 2003 but is it still applicable today? What are some of the caveats using one over the other?
There's a pretty good comparison chart on MSDN.
Website projects are simple, in that all files added to the project folders are automatically compiled and included, which was supposedly added to make it more palatable to classic ASP and PHP developers. Once benefit is that it includes build providers, which allow for certain actions to be associated with a filetype - that's how the first release of SubSonic would rebuild the data access layer when you added a .abp file to the site.
Web Application Projects are a lot more flexible, though. For instance, all class libraries in a Website Project need to be in the App_Code folder, which is frustrating in a complex application. There are a lot of scenarios which just don't work for a Website Project.
You can convert from one to another, although if you're unsure I'd recommend just starting with a Web Application.
I strongly disagree with some of what the Websites and Web Projects article says.
First, it wasn't any "small" group of developers who rebelled - I'd suggest it was most of us, who had not been asked if we wanted to totally change the way we developed. They certainly didn't ask me if I wanted to lose six weeks of development time figuring out what they did to break a perfectly good web service.
It wasn't some "download" MS released - it was VS2005 SP1, and they released it pretty damned fast.
In their plusses for projectless development, the "Copy Project" command works very well, and we don't have to avoid debug or project files; you can move pages around - if you don't use source control; where do they get that you have to lock the project files in order to collaborate? What are they using for source control?
I'd also add one question to the debate: what's so special about web sites that they should be the only "project" type (as far as I know) that doesn't use a "project" file? I can't think of anything, unless it's that Microsoft thought that web developers were too simpleminded to understand projects.
Of course, if anyone knows of any other Visual Studio "project" type that does not use a project file, I'd be grateful to be informed of it.
Related
I'm looking at the differences between a Web Site and a Web Application on MSDN, and am drawn to the features of a Web Site because I am tasked with devising an architecture in which customers can heavily customize the application we deliver. It seems this feature of web sites would be useful:
You want to be able to update individual files in production by just
copying new versions to the production server, or by editing the files
directly on the production server.
However, I'm also drawn to the MVC architecture because it has built in features for minifying scripts that are delivered to the client. I also kind of like the idea of breaking up the architecture into clean pieces since this is a very large data model we have.
But from what I can tell, these sets of features appear to be mutually exclusive. Is that true? I can't readily figure out how to create an MVC application in which custom views could be dropped in as pure source files, and be able to run, nor can I figure out how to take advantage of any MVC framework when creating a "Web Site" project. Am I missing something or do I have to pick my poison?
Take a look at ASP.NET templates in VS2013. You can create an app with both MVC and WebForms. This will probably give you a good combination of what you need. By default, view files are not compiled, so you'll always be able to publish new files without doing a full push if you want. In fact, VS2012 even allows you to publish select files or folders.
The choice between web site and web app to be is very simple. If you are creating a mostly static app, choose "web site". If you are creating an app that has even a decent amount of dynamic capabilities, choose "web app". Web Sites are not really designed to be dynamic, so the more dynamic you do in that setting, the more of a headache it will be to properly maintain it as the architecture just isn't where it would need to be.
What I would suggest is to spin both of them up and try out some scenarios that you are interested and see what works and what doesn't. Really think about how users will actually want to customize the app. Will they want to copy and paste files to production or would they rather request features and have them built properly? Or maybe they want to work with a workflow instead?
So make realistic business requirements, prototype and then decide. But based on what I'm hearing you want a WebApp and probably one that does MVC and WebForms.
Now everything ONE ASP.Net. You will be creating a WebForm, MVC, Webpages using ASP.Net platform.
Check this video about new features in VS 2013
Not sure you can create website in ASP.Net 4.5.
From my experience, I would go with WebApplication based project, where managing namespace and other stuffs are easy. In website its hard to get the standard name for the classes(randome) generated.
Go with MVC web application.
I have an existing solution in VS2010. When I click the properties of my project I get the view as can be seen in image1.png:
When I create a new empty ASP.NET web application and click the properties of my project I get the view as can be seen in image2.png:
A huge difference.
Now I'm implementing this code here: http://wcf.codeplex.com/wikipage?title=Getting%20started:%20Building%20a%20simple%20web%20api
And that tutorial assumes I get a view as I've shown you in image2.png
In image1 and image2 I've also marked the menu items: "Website" and "Project"
This makes me assume that I've created a website application whereas I need something different (I'm thinking a web application project).
Not sure what to do now, I need to convert my current application to another thing, but to which type and how to do it?
I also came accoss this post: http://blogs.msdn.com/b/webdevtools/archive/2009/10/29/converting-a-web-site-project-to-a-web-application-project.aspx
But before I start screwing up everything :P Is that what would solve my problem?
It should be possible to use either a web site or a web application project. In the example on the link you've posted, they use the predefined template for ASP.Net MVC Web Applications. This has several advantages - it sets up the structure and other resources for you - it's effectively a template.
For the purposes of the tutorial, why don't you just set up an application that way? If you've already written some code, you can just import it into the new application.
For future projects, you might want to consider which is best for your needs. Apart from structure, there are some other key differences between a web application and a web site project.
MSDN handily provides the differences here:
http://msdn.microsoft.com/en-us/library/dd547590.aspx
If you find you want the features of the web application, then the link you've posted is fine. You'll need to do some re-organizing of your references and so on and so forth, but the process is fairly straightforward (but not painless).
A "web site" in visual studio is the old, .net 1 style of creating web sites. It basically dynamically compiles the code in a folder when it's hit for the first time. Later .NET introduced a "web application" model where the code is compiled into a DLL and no code files are deployed with the site. "Web sites" are pretty much depcrated and shouldn't be used for any new projects unless you're doing a quick demo site.
The codeplex project you referenced also depends on MVC 3 (which are web applications).
You are probably better off just restarting like the tutorial says - create a new MVC application like it shows in its first screenshot.
If you do not have that option, use Web Platform Installer to add MVC for you - http://www.microsoft.com/web/downloads/platform.aspx
Good luck!
I can't tell exactly what's going on from your screenshots, but if you have a web site that you need to convert to a web application project, you can find the directions here
Although the instructions are specific to VS2005, they are basically the same for 2010 as well.
This question already has answers here:
ASP.NET Web Site or ASP.NET Web Application?
(25 answers)
Closed 9 years ago.
I'm trying to convince my co-workers to switch from a web site project to a web application project, because I want the use of the project file. However I can't diffuse this argument against:
The web site project allows each page to be compiled into a single dll. Their argument is this enables easy fixing of errors found after publishing. This is contrast to how the web application project compiles all code behind into a single dll.
Is updating a single page's dll essentially different to updating the entire site's dll?
Is there some way to compile each page's code behind into a separate dll in the web application project?
Are there some prohibitive (performance,memory?) costs to compiling each page's code behind into separate dll's that we are unaware of?
Why is the feature(?) to compile each page to separate dlls in web site projects and not web app projects?
I'd say if everyone there needs the flexibility to deploy bug fixes post release without re-releasing the whole site then they are right: you need to have a web project for that sort of dynamic compilation. That or a better testing process ;)
Personally I prefer a web application though since there is only one dll created, which means less mess and less scope for "weird bugs" with dll's having different names etc. If you have a large site you should really be using a web application. I remember making this decision a year ago and I never looked back (I chose web application) :)
I used to favor web applications much more than a web site project. However, I came to realize that if you have a site that requires lots of minor updates, then going with a web project is just easier.
When you can just change one code-behind file, instead of having to rebuild the entire app and deploy - it makes deployment a million times less stressful.
However, if you are using proper version control systems, branching, automated builds, proper QA, then either way works out.
But yes, website projects are a lot easier to "update".
This question already has answers here:
ASP.NET Web Site or ASP.NET Web Application?
(25 answers)
Closed 9 years ago.
I am reading from the following link,
http://reddnet.net/code/asp-net-web-site-vs-web-application-project-part-2/
My two confusions,
What is the so-called issue "No control over your namespaces" cons from a web site project? Could anyone show me a sample to illustrate this issue please?
What is the so-called issue "It is hard (read, nearly impossible) to reference pages, user controls, etc from custom classes in the app_code folder."? Could anyone show me a sample to illustrate this issue please?
I am using VSTS 2008 + .Net 3.5 + C#.
thanks in advance,
George
imagine a WebSite...
that is a simple web app, all alone in the world... remember, you can't add anything else to it, right...?
Now, how about a web project? that it's part of a Solution, and a Solution can have n projects, take my current work for example:
alt text http://www.balexandre.com/temp/2009-06-29_0816_so_question.png
In just one solution, I have more projects than the website, and even if they are in different directories I referenced those projects in the website and it's easy to edit, for example, the ExtensionMethods project when I need to add more.
This is something that you can't control in a WebSite, only in a Web Application Project.
The Web Application Project is like any other project, it includes all files that are in Projects like the proj extension file, and it's treated like a project, for example, you can exclude files to be compiled (you can't in a Website), it is easier to deploy because of the nice plugin called Web Deployment Project", just right click in your WebSite project and choose Add Web Deployment Project...
alt text http://www.balexandre.com/temp/2009-06-29_0825_soanswer.png
And you can deploy only this project (add it to your Web Setup, in order to create the msi file) and you will deploy a compiled website (no source code is showed, all code is compiled into dll's so you can hide the source).
There are numerous advantages to use Web Application Project over a simple Website...
Which Visual Studio template should be used for a ASP.NET web site, the Web Site template or the Project | Web Application template?
you'd better read this:
http://msdn.microsoft.com/en-us/library/aa730880(VS.80).aspx
in my opinion it depends on what you are developing
Both function and perform similarly, but still differ in following ways:
Web application:
We can't include C# and VB pages in single web application.
We can set up dependencies between multiple projects.
Can not edit individual files after deployment without recompiling.
Right choice for enterprise environments where multiple developers work unitedly for creating, testing and deployment.
Web site:
Can mix VB and C# page in single website.
Can not establish dependencies.
Edit individual files after deployment.
Right choice when one developer will responsible for creating and managing entire website.
Web application projects works more like a traditional VS project, which has a project file, is compiled in one step and so on.
Web site projects works more like classic ASP or PHP-sites. There is no project file (references are stored in the solution file), and pages are recompiled dynamically on the server. The nice thing with web sites is that you can just ftp to the server and change a file in a text editor. You dont need VS. Some may hate that, though.
It probably depends on your background. If you are used to ASP or PHP style development, web site projects will seem more natural to you. If you have a traditional application developer background, web application projects will seem more natural.
If you're using Team Foundation Server for source control, you'll probably have to use a Web Application Project, as you need a .csproj file.
There are more details from Jeff Atwood himself: Web Site Projects vs. Web Application Projects
Web Site web projects are particularly painful in Team System due to the lack of a physical file that contains project information and metadata. For example, it's impossible to check in code analysis rules on Web Site projects, because the code analysis rules are stored entirely on the client!
I prefer a website. A website is a collection of files in a directory. It becomes more portable and deployable. A web application clouds the issue with a project file.
Personally I use web application projects exclusively now. I actually converted a rather web site to a web application because of compilation times for the web site.
I also use pre-build events to move configuration specific configuration files around and pre-build and post-build events are not available in web sites.
In Visual Studio 2015, I've come to somewhat prefer web site projects over web app projects. I still use visual studio though because you get Nuget Packaging, you can install nuget packages to both types of projects.
However a WebSite Project does not have a project file, you are literally just adding a folder to your solution.
However you can still have code, but I prefer to put it in a separate project.
In WebApp projects you have your Assets, Css, Views (razor, aspx etc), Controllers/Code Behinds etc all in one project and it just mashes together. I prefer to work with websites in two halves. The front end (css, js, images, "html/cshtml/aspx/ashx/.master/etc") and the back end (all the code).
So I create a Web Site project and a class Library to accompany it (in visual studio you can add references to the web site project). I add my class Library as a dependency and all Code is in the class Library. You can still have a global.asax, you just have to tell it that the code behind is in another dll (not the one that the site will compile to). MVC views, you just specify the namespaces like normal (the dll is referrence so the namespaces are there). And in WebForms you Just have to remember to include the assembly name with your type references that the code is in.
It's a little tedious to get use to, but when you do you have isolated structure, everything is in a place that makes sense and modularized in an easy to maintain way.
And the PLUS side is that because the Web Site is just a folder (no project file) it can be opened in Visual Studio Code easily, and other popular text editors making it easy for designers to work on the css/js/images etc (which are not in the code project). Keeping the layer designers separated, the designer sees just what they need to see.
Now structure wise. I keep my code local on my machine checked into a subversion repository using Tortoise SVN and Visual SVN (java/.net shop). To test locally I install IIS and I set the website project up in IIS locally just like I would on the dev/prod servers.
Then I install MSDeploy on the dev/prod servers and I use the Publish web app feature via MSDeploy in visual studio and I use web.config transformations. So I have web.config transformations for dev and prod and the main web.config without transformations is for local testing (so it works for all devs on the project).
To previous stated cons: Having a WebSite Project vs a WebApp Project doesn't mean multiple developers can't work on it, that's only if your WebSite Project is on some server some where and you are loading it directly from there which would be bad practice.
You can treat a WebSite Project just like any other Visual Studio project, local code, source control, multiple developers.
As a final note, an added benefit of separating your code is you can put all of your code in a shared project. Then you can create a Class Library for each port you might do, say one on straight .net 4.6 and another on .net core 5 and link in your shared project. As long as your code is compatible with both, it will build and you don't have any duplicated code files.