I am reading currently Professional Asp.net by wrox and one thing cought my attention. Authors say that after every request to site, if specific site isnt yet compiled, asp.net engine is running compilation. After that this specific site in our app isnt recompiled with every next request - just during the first one. But this dont really make sense to me, because after we compile our site with aspnet_compiler, the output contains only single dll for all of pages in our app. So my question is - are there any diffirences in compiled files structure between an app precompiled with aspnet_compiler and the app which is compiled on-fly during first requests to specific pages in application.
My understanding is that when you build your website in visual studios the dll's that get produced come from your .cs files(or .vb depending on what language you are using). Any files that could contain server-side code and html (e.g. .aspx or .ascx) are not compiled at this time but rather the first time a user hits them and not any of the .cs files. See here read the dynamic compilation section.
Although code files in the project are precompiled into a single assembly by using MSBuild, ASP.NET Web pages (.aspx) and user controls (.ascx) of a Web application project are compiled dynamically on the server by the ASP.NET compiler1
Your question is a bit vague. Is there any difference? What kind of difference are you referring to? Structure? What do you mean by the structure?
aspnet_compiler does what happens at runtime in the typical configuration, but it does it at compile time rather than runtime. The code it produces is basically the same as what will eventually run.
There is, however still a compilation that must take place. aspnet_compiler, just like the cs or vb compilers, only compile to byte code. The byte code must still be compiled to native code at runtime, unless you ngen it when you install it.
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 a VB.NET web application in VS2015 that seems to be recompiling whenever I touch an .ascx file (then my session is lost and I have to re-authenticate). I don’t have this behavior if I touch an .aspx page. I always assumed that I could change the markup without recompiling, and in fact have done it a number of times in previous projects.
I understand the differences between a web application project and a web site project in ASP.NET. Here we’re talking about a web application (project GUID 349c5851-65df-11da-9384-00065b846f21) that compiles all the code-behind files into a single DLL.
I have to make a lot of markup and CSS changes that I want to see reflected in the UI without having to recompile, and this is getting quite painful.
you should be able to merge the assemblies... but just wondering if you had a VB.net web app, and then had a C# project, how would you merge the aspx pages?
can it be done?
For Web Site projects, you can place your C# source code files in App_Code\CS and your VB.NET files in App_Code\VB. Your ASPX files can be either language, as stated in the #Page directive.
For Web Application projects, you are limited to one language per project. You can deploy as many projects of different languages as needed.
You can easily mix VB and CS projects in the same solution. Suposedly (see link below) you are able to mix them within the same project. I have never tried the method specified below though so I can't tell you if it actually works. There is no IDE support for it though:
Mixing C# and VB.NET in one assembly
You might be able to take two projects, built independently into aspx files and a dll, and deploy the aspx files and the two dlls to the bin directory. It might work,but I don't know how well something like Global.asax will handle that, since those methods would be in both dlls.
If they're both deployed to the same folder in IIS, there is nothing stopping you from having some .aspx files in C# and some in VB.NET. Obviously, in one Visual Studio project, you can only have all-VB.NEt or all C#, but you can still deploy two projects to the same web application.
I would question the value of this in general, though, since it means your developers will need to be familiar with both languages. We have done this in the past, though, when writing DotNetNuke modules - DotNetNuke itself is written in VB.NET (for some bizarre reason), and we developed our custom modules in C#.
Is there any performance benefit to pre-compiling an asp.net web application if it's set to be updateable? By setting the pre-compiler updateable flag it doesn't pre-compile the aspx, ascx, etc. so those still have to be compiled at run-time on the first page load. Everything else in an ASP.NET Web Application Project is already compiled anyways though, so what is the point of running the pre-compiler on a WAP with the updateable flag set to true?
The only performance benefit is that it pre-compiles the associated code-behind files for your ASPX and ASCX files.
ASP.NET aims for performance benefits over other script-based technologies (including Classic ASP) by compiling the server-side code to one or more DLL files on the web server.[18] This compilation happens automatically the first time a page is requested (which means the developer need not perform a separate compilation step for pages). This feature provides the ease of development offered by scripting languages with the performance benefits of a compiled binary. However, the compilation might cause a noticeable but short delay to the web user when the newly-edited page is first requested from the web server, but won't again unless the page requested is updated further.
The ASPX and other resource files are placed in a virtual host on an Internet Information Services server (or other compatible ASP.NET servers; see Other Implementations, below). The first time a client requests a page, the .NET framework parses and compiles the file(s) into a .NET assembly and sends the response; subsequent requests are served from the DLL files. By default ASP.NET will compile the entire site in batches of 1000 files upon first request. If the compilation delay is causing problems, the batch size or the compilation strategy may be tweaked.
Developers can also choose to pre-compile their code before deployment, eliminating the need for just-in-time compilation in a production environment. This also eliminates the need of having the source code on the web server.
(Taken directly from the wikipedia page) A great explanation of the benefits of compiling your code over scripted code such as php or class ASP.
From what I can tell in this specific case there isn't a performance benefit to pre-compiling a WAP when it's set to updateable for the reasons listed in the question.