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...
Related
I am taking over a legacy ASP.NET Web Forms application written a long time ago. The application does not come with a .csproj file or a VS .sln file. All DLL libraries are simply added to the bin folder and referenced directly in code. All CS classes are added to the app_code folder and referenced in code.
We are trying to integrate this site to make use of CI / CD pipelines but it has been very challenging. Part of it is because we cant make use of MSBuild because we don't have a project file or a solution file.
I was wondering if anyone has been in a similar situation before. What would be the best way to create a project and / or solution file for this? Do we need to have both a project file and a solution file? Any guides out there you can point to on how to do this?
I hope my question is clear. Thanks in advance!
The application does not come with a .csproj file or a VS .sln file
That is normal for a asp.net web site. No sln, or project files are required.
Of course that means you do NOT open the site by using open project, but open the site by using open web site. As such, no csproj or even a project (sln) file is required, or should even exist.
All DLL libraries are simply added to the bin folder and referenced directly in code
Again, that's quite normal for web site.
For a web site "application", then references to external libraies and .dll's (assmeblies) is much like desktop. You add these refrences. then at deploy time, visual stuido will build, compile, and move all the .dll's into the bin folder for you. And you even have options to "merge" such .dll's into one .dll at publish time.
At this point in time, if you can open the site site, view a web page, and then say right click, and view code, then you are in great shape.
However, it is ALSO possible that your web site folder is the RESULT of a asp.net web site "application". If that is the case, then the web site will NOT have the code behind, since Visual studio did the compile. When you use a asp.net web site (not a asp.net web site application), then both the markup pages, and the code behind pages should exist. This ALSO means that the web site (IIS) does the compile of code, and NOT visual studio.
so, the only detail you need to determine?
Does the web site have BOTH the markup pages, and ALSO has the source code (code behind) pages? If you do not have the code behind pages, then you don't have a web site, but have the "results" of a web site application publish. This means you don't have the code behind (source code).
But, opening a web site from visual studio does not need nor require a project file, nor does it require sln file.
so, I guess the base question (that will quite much answer all of the above points and questions?
do you see + have the code behind pages on that site? Since if you do not, then you have to go find and get the original project used to publish that web site application, and without as such, you not only missing the source code, but all of the references etc. that are saved in the project file(s).
What would be the best way to create a project and / or solution file for this?
Gee, if this is a web site and not "application", then you may well not want to do this (at least not yet). There are quite a few advantages of keeping and using a web site as opposed to a web site application, and one issue will be setup of all the references.
Also, web servers tend to be far more tolerent of accepting a web site, then a web site application. (for example, it boatloads easier to copy or ftp a web site to a sub site in a folder on the web server.
If the main startup page is the main page of the web site, then it without question a lot easier to say convert, and open the folder as a project, and thus the sln file will be created. However, quite a few assumptions will have been made based on "application" vs non application, and if that's how the system was setup, then little advantages exist to now try and convert to a web application.
The other huge advantage? with a web site, you can modify one line of code, save, and you are done.
With a web site application, you change just one line of code, and you now have to re-publish the WHOLE site. So, while I without question prefer the application road? You noted in your post that you want to keep agile development, and if that is your goal, then hands down keeping this as a web site is a far better choice. You can change one line of code, save, and if that page + code is moved to the server, you are done.
so, a application is far more formalized, but quite much kills the agile development goal you noted in your post.
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".
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.
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.