Differences Between Website Compilation and Web Application
There are many variations of ASP.NET modules based on different platforms, such as Web Forms, Web Pages, Model-View-Controller (MVC) and the newest Core. In this article I want to consider a number of differences between the compilation of an ASP.NET website and an ASP.NET web application.
Compilation of the website (Fig. 1) and web applications (Fig. 2).
')
Fig. 1: ASP.NET website and the difference between an ASP.NET website and an ASP.NET web application
Fig. 2: ASP.NET Web Application and the Difference between an ASP.NET Web Site and an ASP.NET Web Application
This article is not about the internal structure of ASP.NET projects, but about the experience that I gained while working on the Azure App Service platform. The internal structure is already documented here - “Precompiling Your Website (C #)” (“Precompiling a website in C #”). You need to understand the difference between automatic and explicit compilation. In addition, if you are dealing with an ASP.NET website, seriously consider precompiling using aspnet_compiler.exe, as described in the article “How to: Precompile ASP.NET Web Sites” (“How to precompile websites ASP.NET ").
Here are a number of publications that will help you expand your horizons on this issue and explore other topics:
So, how did it all start? I wanted to check whether I understand the process of compiling ASP.NET modules into assemblies correctly, and decided to do it in the Azure App Service environment. I already knew about temporary ASP.NET files, about compiling ASPX files into a .dll assembly, and where they were stored on a standalone server. I was sure that on the App Service platform, the first two items were implemented in the same way, but I doubted the third one, namely, where the compiled assemblies are stored. So I wrote the code to find out.
Then I published this code on the App Service platform.
When I first accessed the website, I got the result shown in fig. 3 (initially there were three pages in the root of my ASP.NET website)
Fig. 3: Compile an ASP.NET website on the Azure App Service platform
I restarted the website, and the binaries compiled into the new build (Figure 4). This was rather unexpected, since I only performed a reboot and did not make any deployments or changes.
Fig. 4: Compile an ASP.NET website on the Azure App Service platform
I searched the build directory in KUDU and did not find it; it was very strange.
After clicking the “Another Page” and “And another Page” links, all my pages were compiled into one assembly, and I was quite surprised to find this, because my web.config file was set to debug = true.
I needed to find out the answers to the following questions:
The answer to the first question was that I was actually looking at the KUDU build, and not the one that was compiled for the App Service. Take a look at Figure 2 in the article “Create a memory dump for your slow performing Web App”. Here it is shown that KUDU works in a different process than App Service. So KUDU recompiled itself when creating an instance, and it was not my instance of App Service.
I also dealt with the second question on the basis of information obtained on the first question. I’ll omit the details about the configuration of files on the App Service platform and say that I managed to display my ASP.NET web site assemblies on this platform: for this I set the WEBSITE_DISABLE_SCM_SEPARATION value to true (see Figure 5). Do this only for testing and / or debugging and for nothing more. I do not recommend matching multiple pages of a website to a single process in the App Service. After debugging, reset this value and re-divide the processes.
Fig. 5: Compile an ASP.NET website into an Azure App Service; I can not find temporary files ASP.NET on KUDU
The answer to the third question was that if the Web.Debug.config file is present during the deployment process, the debug = true attribute is deleted.
I wrote about XDT files here , here and here , but in this case I had to think a little bit in order to understand (remember, realize) their meaning.
After setting the WEBSITE_DISABLE_SCM_SEPARATION parameter to true, I stopped and started, in other words, cold start ... and saw that in fact both SCM / KUDU and my website started up in the same process (Fig. 6.)
Fig. 6: Compile the ASP.NET website into the Azure App Service; I can not find temporary files ASP.NET on KUDU
Publication and compilation of default.aspx is initiated, the name of the assembly remains unchanged after all requests (Fig. 7).
Fig. 7: Compile an ASP.NET website on the Azure App Service platform
To verify this, I took a memory dump of the process, took a dump of the module and analyzed it. Honestly, I was still puzzled by the result displayed by the resulting assembly, as I figured out the debug = true parameter only after all the tests were completed. Sometimes I do not write articles in the order in which events follow. In confusion, I decided to test the batch compilation; read about it here : “Compilation Element (ASP.NET Settings Schema)” (“Compilation Element - ASP.NET web settings schema”). I expected that one build would be compiled per page, so the result (see Figure 8) came as a complete surprise.
Fig. 8: Compile an ASP.NET website on the Azure App Service Platform
I expected to see one build per page, since I thought that I was working with the parameter debug = true. Reading about batch compilation, I realized that it compiles all pages into an assembly contained in a specific directory. So I created two directories and placed aspx files in each of them. The PID did not change, so there was no “cold start” (Fig. 9).
Fig. 9: Compile an ASP.NET website on the Azure App Service platform
However, the site was indeed recompiled into another binary file, but remained in the same directory (path) (Fig. 10).
Fig. 10: Compile an ASP.NET website on the Azure App Service platform.
I made a memory dump to make sure my conclusions were correct. And as soon as I turned to the site root and saw that all the pages in the catalog were compiled, I realized that my hypothesis about batch compilation was confirmed (Fig. 11).
Fig. 11: Compile an ASP.NET website on the Azure App Service platform
I followed the “Directory 1” link and saw another build (fig. 12).
Fig. 12: Compile an ASP.NET website on the Azure App Service platform.
I did a memory dump again, took a module dump and saw that it really corresponds to the “Directory 1” page (Figure 13).
Fig. 13: Compile an ASP.NET website on the Azure App Service platform
I did the same for the “Directory 2” page (Fig. 14 and 15).
Fig. 14: Compile an ASP.NET website on the Azure App Service platform.
Fig. 15: Compile an ASP.NET website on the Azure App Service platform.
I also got the opportunity to go to the assemblies themselves in SCM / KUDU (Fig. 16).
Fig. 16: Compile an ASP.NET website on the Azure App Service platform
As soon as I found out the problem with the parameter debug = true, everything fell into place, and it was a good learning experience. I hope that my article will be useful for you.
Use a structured approach to developing cloud applications. This 300-page e-book on cloud computing architecture discusses architecture, development, and deployment recommendations that apply regardless of the cloud platform chosen. This guide includes steps to:
→ Download
From this update to the Azure Developer’s Guide, you’ll find out how a complete set of services for the Azure software platform fits your needs. Here you will find information about architectural approaches and the most common situations that arise when creating cloud applications.
→ Download
This book provides insight into important information about Azure key services for developers and IT professionals who are not familiar with cloud computing. Step-by-step demos are included to help the reader understand how to get started with each of the key services. Each chapter is independent, no practical demonstrations from previous chapters are required to understand a particular chapter.
This book covers the following topics:
→ Download
Compilation of the website (Fig. 1) and web applications (Fig. 2).
')
Fig. 1: ASP.NET website and the difference between an ASP.NET website and an ASP.NET web application
Fig. 2: ASP.NET Web Application and the Difference between an ASP.NET Web Site and an ASP.NET Web Application
This article is not about the internal structure of ASP.NET projects, but about the experience that I gained while working on the Azure App Service platform. The internal structure is already documented here - “Precompiling Your Website (C #)” (“Precompiling a website in C #”). You need to understand the difference between automatic and explicit compilation. In addition, if you are dealing with an ASP.NET website, seriously consider precompiling using aspnet_compiler.exe, as described in the article “How to: Precompile ASP.NET Web Sites” (“How to precompile websites ASP.NET ").
Here are a number of publications that will help you expand your horizons on this issue and explore other topics:
- "Why is my ASP.NET application recycling, restarting" ("Why an ASP.NET application is recompiled, reloaded")
- "Must use, must know WinDbg commands, my most used" ("WinDbg commands that you need to know and use and which I use most often")
- Lab 28: The impact of debug = true ("Session 28: the effect of debug = true")
- “Debug = True”
- All my articles on ASP.NET
So, how did it all start? I wanted to check whether I understand the process of compiling ASP.NET modules into assemblies correctly, and decided to do it in the Azure App Service environment. I already knew about temporary ASP.NET files, about compiling ASPX files into a .dll assembly, and where they were stored on a standalone server. I was sure that on the App Service platform, the first two items were implemented in the same way, but I doubted the third one, namely, where the compiled assemblies are stored. So I wrote the code to find out.
public partial class _default : System.Web.UI.Page { protected void Page_Load(object sender, EventArgs e) { LabelFileLocation.Text = $"{System.Web.HttpRuntime.CodegenDir}"; rptResults1.DataSource = System.IO.Directory.GetFiles(System.Web.HttpRuntime.CodegenDir, "*.dll"); rptResults1.DataBind(); } } () <asp:Repeater ID="rptResults1" runat="server"> <HeaderTemplate><table></HeaderTemplate> <ItemTemplate> <tr> <td><%# Container.DataItem %></td> </tr> </ItemTemplate> <FooterTemplate></table></FooterTemplate> </asp:Repeater> Then I published this code on the App Service platform.
When I first accessed the website, I got the result shown in fig. 3 (initially there were three pages in the root of my ASP.NET website)
Fig. 3: Compile an ASP.NET website on the Azure App Service platform
I restarted the website, and the binaries compiled into the new build (Figure 4). This was rather unexpected, since I only performed a reboot and did not make any deployments or changes.
Fig. 4: Compile an ASP.NET website on the Azure App Service platform
I searched the build directory in KUDU and did not find it; it was very strange.
After clicking the “Another Page” and “And another Page” links, all my pages were compiled into one assembly, and I was quite surprised to find this, because my web.config file was set to debug = true.
I needed to find out the answers to the following questions:
- Why did my application recompile after a reboot, although I did not perform any deployments or configuration changes?
- Why did I not find the build in KUDU, although my source code was correct?
- Why did my application compile into a single assembly, although the debug = true parameter was set in the web.config file?
The answer to the first question was that I was actually looking at the KUDU build, and not the one that was compiled for the App Service. Take a look at Figure 2 in the article “Create a memory dump for your slow performing Web App”. Here it is shown that KUDU works in a different process than App Service. So KUDU recompiled itself when creating an instance, and it was not my instance of App Service.
I also dealt with the second question on the basis of information obtained on the first question. I’ll omit the details about the configuration of files on the App Service platform and say that I managed to display my ASP.NET web site assemblies on this platform: for this I set the WEBSITE_DISABLE_SCM_SEPARATION value to true (see Figure 5). Do this only for testing and / or debugging and for nothing more. I do not recommend matching multiple pages of a website to a single process in the App Service. After debugging, reset this value and re-divide the processes.
Fig. 5: Compile an ASP.NET website into an Azure App Service; I can not find temporary files ASP.NET on KUDU
The answer to the third question was that if the Web.Debug.config file is present during the deployment process, the debug = true attribute is deleted.
<compilation xdt:Transform="RemoveAttributes(debug)" /> I wrote about XDT files here , here and here , but in this case I had to think a little bit in order to understand (remember, realize) their meaning.
After setting the WEBSITE_DISABLE_SCM_SEPARATION parameter to true, I stopped and started, in other words, cold start ... and saw that in fact both SCM / KUDU and my website started up in the same process (Fig. 6.)
Fig. 6: Compile the ASP.NET website into the Azure App Service; I can not find temporary files ASP.NET on KUDU
Publication and compilation of default.aspx is initiated, the name of the assembly remains unchanged after all requests (Fig. 7).
Fig. 7: Compile an ASP.NET website on the Azure App Service platform
To verify this, I took a memory dump of the process, took a dump of the module and analyzed it. Honestly, I was still puzzled by the result displayed by the resulting assembly, as I figured out the debug = true parameter only after all the tests were completed. Sometimes I do not write articles in the order in which events follow. In confusion, I decided to test the batch compilation; read about it here : “Compilation Element (ASP.NET Settings Schema)” (“Compilation Element - ASP.NET web settings schema”). I expected that one build would be compiled per page, so the result (see Figure 8) came as a complete surprise.
Fig. 8: Compile an ASP.NET website on the Azure App Service Platform
I expected to see one build per page, since I thought that I was working with the parameter debug = true. Reading about batch compilation, I realized that it compiles all pages into an assembly contained in a specific directory. So I created two directories and placed aspx files in each of them. The PID did not change, so there was no “cold start” (Fig. 9).
Fig. 9: Compile an ASP.NET website on the Azure App Service platform
However, the site was indeed recompiled into another binary file, but remained in the same directory (path) (Fig. 10).
Fig. 10: Compile an ASP.NET website on the Azure App Service platform.
I made a memory dump to make sure my conclusions were correct. And as soon as I turned to the site root and saw that all the pages in the catalog were compiled, I realized that my hypothesis about batch compilation was confirmed (Fig. 11).
Fig. 11: Compile an ASP.NET website on the Azure App Service platform
I followed the “Directory 1” link and saw another build (fig. 12).
Fig. 12: Compile an ASP.NET website on the Azure App Service platform.
I did a memory dump again, took a module dump and saw that it really corresponds to the “Directory 1” page (Figure 13).
Fig. 13: Compile an ASP.NET website on the Azure App Service platform
I did the same for the “Directory 2” page (Fig. 14 and 15).
Fig. 14: Compile an ASP.NET website on the Azure App Service platform.
Fig. 15: Compile an ASP.NET website on the Azure App Service platform.
I also got the opportunity to go to the assemblies themselves in SCM / KUDU (Fig. 16).
Fig. 16: Compile an ASP.NET website on the Azure App Service platform
As soon as I found out the problem with the parameter debug = true, everything fell into place, and it was a good learning experience. I hope that my article will be useful for you.
Useful resources
Cloud Application Architecture Guide
Use a structured approach to developing cloud applications. This 300-page e-book on cloud computing architecture discusses architecture, development, and deployment recommendations that apply regardless of the cloud platform chosen. This guide includes steps to:- Choosing the right style of the cloud application architecture for your application or solution;
- selection of appropriate computing and data storage technologies;
- implementation of 10 development principles for creating a scalable, fault-tolerant and managed application;
- following the five principles of creating high-quality software that guarantees the success of your cloud application;
- using constructive patterns intended for the problem you are trying to solve.
→ Download
Azure Developer Guide
From this update to the Azure Developer’s Guide, you’ll find out how a complete set of services for the Azure software platform fits your needs. Here you will find information about architectural approaches and the most common situations that arise when creating cloud applications.
→ Download
Microsoft Azure Basics
This book provides insight into important information about Azure key services for developers and IT professionals who are not familiar with cloud computing. Step-by-step demos are included to help the reader understand how to get started with each of the key services. Each chapter is independent, no practical demonstrations from previous chapters are required to understand a particular chapter.This book covers the following topics:
- Get started with Azure;
- Azure App Service and Web Apps;
- Virtual machines;
- Storage service;
- Database;
- Additional Azure services.
→ Download
useful links
Source: https://habr.com/ru/post/421995/
All Articles