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.
CodePudding user response：
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.