Is there any difference between website and web application project? What if you are working on a project that is sort of hybrid of site and application? which project should you chose?
I'ld go the newer Web Application project (always, regardless of the size of the project).
There is nothing to lose and everything to gain with using the Web Application Project (you cannot say this about using the "website" only).
The official list of differences are here:
Use Web Application Projects when you
Need to migrate large Visual Studio.NET 2003 applications
Need to
control names of output assemblies
Need stand-alone classes to
reference page and user control
classes
Need to build a Web
application using multiple Web
projects
Need to add pre-build and
post-build steps during compilation
Use Websites if you:
Need to generate one assembly for each page.
Prefer single-page code model to code-behind model.
Prefer dynamic compilation and working on pages without building entire site on each page view (that is, save file and then simply refresh the page in the browser).
Want to open and edit any directory as a Web project without creating a project file
#Mehrdad's link here is essential if you want to know more http://msdn.microsoft.com/en-us/library/aa730880(VS.80).aspx#wapp_topic5
As for which project to choose, I would go with the Web Application Project, regardless of size. Having all of your code behind compile down into a single DLL is a major benefit for maintenance and security on the hosting end. I know there are precompile options for web site projects, but they seemed like more trouble that it was worth for me.
I know that the IIS filters are in place to prevent users from accessing your .vb or .cs files, but it still makes me a little leery.
But more important to this is the nice fact that if you make a bunch of coding changes, or maybe add some classes and change the processing logic, the only thing you have to merge up is the compiled DLL and nothing else. Similarly, if you do a few UI changes (say change the stylesheet or position of a few controls), you don't have to worry about recompiling the application, you simply bring over the update .aspx page and you're done.
Take a look:
http://msdn.microsoft.com/en-us/library/aa730880(VS.80).aspx#wapp_topic5
http://forums.asp.net/p/1300026/2538628.aspx
I'm used to create websites when I want to create a new webapplication.
My current project had some problems on compiling, so I switched to a webapplication project. The step isn't very hard. Visual Studio helps you to change all necessary lines.
Refer to the links in the post:
http://www.codersbarn.com/post/2008/06/01/ASPNET-Web-Site-versus-Web-Application-Project.aspx
Anthony :-)
Related
I have created a new ASP.NET (.net framework) website (not core) and when i run the project i get the following files created in the bin folder - website.dll, website.dll.config, website,pdb.
1) Are these always created for websites?
I would prefer not to have them because when i want to make a change to a .cs file the dll needs to update which will reset all sessions.
2) How can this be done?
I have previous asp.net websites and these files never got created so i am a little confused. old net versions don't do it?
FYI Project settings - .NET Framework 4.7.2 and the output type is class library (other options are console application and console application.
You have two types of asp.net webform projects.
A)
A asp.net web site.
These sites are thus not really a visual studio project. When you create a asp.net web site, then you don't use file->open->project, but use file->open web site.
With such above site, each asp.net page will have a corresponding cs, or vb.net page for the code behind. And you can modify ONE page (say the markup, or code), hit save, and you are done. Such pages (and the code) is compiled on the fly by IIS (the web server).
A lot of people do like the above setup, since in many cases, if the web server is on your same network, you can open the live site directly. Make some changes, hit ctrl-s, and you are done. Of course EVERY page used thus results in a .dll being created.
So, above is still a option you can use (and what you likey were using in the past)
However, there is a 2nd choice,
Asp.net web site application.
The key word/term here is "application".
In a asp.net web site application, then you have a standard sln (project file), and you have to re-build and re-compile the WHOLE site before a new update or deploy.
this means that even changing ONE line of code behind forces you to do a FULL re-deploy of the web site. However, while this is somewhat more "pain" for a new deploy, it is still a far more controlled environment. This choice also means that visual studio (vs) does the compiling BEFORE deploying.
There are significant advantages to this setup. You can include multiple projects and assemblies (and get FAR BETTER compile time resolution). So, the more advanced a developer, the more say using git, and adopting use of class library's and objects?
And the more compile time checking, and the more you adopt class objects and liraies for your devleopment cycle? The more you perfer the applcation approch to software development. As noted, there is that ONE BIG penalty for the enjoyment of far better managment of referances, compiling, and management of a larger project - you lose the "one quick and dirty" deployment option.
So, you have to pre-compile the site/code, and then run it. IIS does not do the compiling (and more important than the management of those other external code libraries). In most cases, with a web site, to add new assemblies to your project, the .dll's will be placed in the bin file. (and I don't like that at all).
I far perfer when I do a clean project, that the WHOLE bin folder and ANY dll's are 100% blowen out of the water, and don't exist anymore. If you use a web site, then you will and MUST have a hodge podge of .dll's strewn all over the place. And EVERY single page with code behind creates a .dll.
So, while your hands are somewhat "more tied" with a asp.net web site application, from a developer point of view, the advantages far outweigh the additional work/effort to deploy.
I have zero, but BEYOND zero idea why you feel or don't like the idea of all of your referenced assemblies at compile time being managed for you, and they all get compiled, and placed in the bin folder for you. Be it a desktop applcation, a console application, or whatever? The hallmark of the compile process was and is to gather up all of your referenced assemblies and .dll's and dump/place/compile/manage/put them into the bin folder for you.
Better yet? When you publish, you can choose options to "merge" all of the .dll's into one dll. This really is much like using a linker for software development.
The other big advantage, is you can say develop with new rosyln compile features. (free form text for sql is really nice). Since vs is doing the compile for you, then you do NOT have to ensure that the web site and IIS requires the advanced compiler options.
So, much of which one you perfer comes down to:
Do you value developer features, better compile time resolving of assemblies, having VS compile the code for you, or do you want to toss out the code to the web site, and have IIS do the compile?
The above also means that your web site will require the source code when using the web site option. This can be someone of a issue for some developers, or even security. Since any modifying of such web pages will automatic trigger IIS to re-compile that page + code for you.
With a asp.net web site application, then no server IIS compile of your code occurs, and better yet, at compile time the .cs (or vb) pages are stripped out, source code is stripped out, and the source code pages (code behind) NEVER is placed on the server. You thus ONLY get the .dll's and the source aspx pages, but NOT the source code pages published on the server.
As of vs version 2022, BOTH template options are supported. So, if you want to use or go back to use web site as opposed to application development? You can make that choice. Just use file->open webs site, and don't use the .sln (project file) anymore.
And you can when creating a new web site choose "asp.net web site", or choose the preferred (by many) the "asp.net web site application".
So, for a lot of sites - especially those a bit older, often developers choose the web site option - the deployment and update is really far less hassle and is done with far greater ease then a application choice. Despite this greater ease of making small updates to the web site, I still far prefer the application choice, since it has far better options in terms of referencing, compiling, and just overall general application management features. Might not matter for your case, and if the current site was a web site (not web site application), then I do suggest you continue and keep that code and site "as is", as opposed to converting to a application.
It seems strange that your panties are all twisted up over having some .dll's appear in the bin folder at compile time, as opposed to a HUGE MOUNTIN of .dll's created for EVERY web page + code behind as what occurs when using a web site.
This compile time and dumping of .dll's into the bin folder? It how all console, desktop, and more .net applications has worked for over 20 years of .net. Can't possibly be a surprise to any .net developer, and in fact most will be confused and miss this approach to software when using a web site - since now IIS is doing the code compile - and not you nor is visual studio.
So above should clear up the difference between the two choices, and why you are seeing a different behavior from past projects. Sounds like that past project was a web site, and not a web site application.
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.
Is it possible to view the change of a page inside Web Application Project without building the whole web application project and its dependent library projects?
Thanks.
I don't think you need to build any referenced projects (unless you have made changes in them), but you will need to build the web project
That's the big advantage of the web site model, which supports partial compilation:
Well described here:
http://www.west-wind.com/presentations/aspnetcompilation/aspnetcompilation.asp
You can view the change of a page without re-building the whole project only if you change a front end of a page. After changing front end, save it, and then refresh browser. If back end changes, you will need to re-build the whole application.
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.