Differences Between Website Compilation and Web Application

Original author: benjamin perkins
  • Transfer
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).


Figure 1: ASP.NET website and the difference between an ASP.NET website and an ASP.NET web application . 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 I gained while working on the platform. Azure App Service. 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 with aspnet_compiler.exe, as described in article“How to: Precompile ASP.NET Web Sites” (“How to precompile ASP.NET websites”).

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.

publicpartialclass _default : System.Web.UI.Page
    protectedvoidPage_Load(object sender, EventArgs e)
        LabelFileLocation.Text = $"{System.Web.HttpRuntime.CodegenDir}";
        rptResults1.DataSource = System.IO.Directory.GetFiles(System.Web.HttpRuntime.CodegenDir, "*.dll");
Я представил результаты следующим образом (обобщенно)
<asp:Repeater ID="rptResults1" runat="server">
    <td><%# Container.DataItem %></td>

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)

Figure 3: Compile an ASP.NET website on the Azure App Service platform.

I restarted the website, and the binaries compiled into a 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:

  1. Why did my application recompile after a reboot, although I did not perform any deployments or configuration changes?
  2. Why did I not find the build in KUDU, although my source code was correct?
  3. 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. Therefore, KUDU recompiled itself when creating an instance, and it was not my instance of App Service.

With the second question, I also figured out on the basis of information obtained on the first question. I will omit the details of 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 several pages of a website to a single process in the App Service. When you finish 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 the temporary ASP.NET files 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.)

. 6: Compile the ASP.NET website into the Azure App Service; I can not find the temporary ASP.NET files on KUDU. The

publication and compilation of default.aspx is initiated, the assembly name 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 per page would be compiled, 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, because 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 did recompile into another binary file, but remained in the same directory (path) (Figure 10).

Fig. 10: Compile an ASP.NET website on the Azure App Service platform.

I made a memory dump in order to fully verify the correctness of my conclusions. 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 clicked on the “Directory 1” link and saw another build (Figure 12).

Fig. 12: Compiling an ASP.NET website on the Azure App Service platform

I again dumped the memory, 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

. 15: Compile an ASP.NET website on the Azure App Service platform.

I also got the opportunity to go to the builds themselves in SCM / KUDU (Figure 16).

Fig. 16: Compiling an ASP.NET website on the Azure App Service platform.

As soon as I figured out the problem with the debug = true parameter, 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 you choose. This guide includes steps to:

  • Choosing the right style of 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 designed for the problem you are trying to solve.


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.


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.


useful links

Also popular now: