What are the tradeoffs for the different merge settings for Azure publish?

Question

When you publish through Visual Studio to Azure, you have the option to precompile your pages. There are quite some options that explain what it does, but nothing about the trade-offs.

• Why wouldn't I check 'Allow [...] to be updatable'?
• Why merge into one file? Is this faster? Does it load faster or compile faster?

There is some information on the Microsoft site, but on above points they are not diving really into it.

https://msdn.microsoft.com/en-us/library/hh475319(v=vs.110).aspx

Answer 1

I found information about these options scattered on different pages of Microsoft's documentation. Here is what I found by putting things together:

---

Why wouldn't I check 'Allow precompiled site to be updatable'?

This might answer your question:

If a compiled site is updatable, UI content can be updated without recompiling the site. When a Web site is updatable, the content files remain in their original folders and only the associated code files are merged. If the site is not updatable, .ascx, .master, and .skin content files are removed from their original folder. ASP.NET .aspx files are replaced with a marker file that has no content. UI content and code are merged in this case.

Source: https://msdn.microsoft.com/en-us/library/bb397866.aspx

An updatable site stores the source file of the UI content and does not compile it. Only the non-UI code is precompiled. This makes updating the site really easy since you can change the code of one webpage without having to precompile the whole website. The down side of this option is that the web pages cannot be precompiled and are compiled every time a user requests the page (minus the caching that might occur). This will reduce performances of page loads.

---

Why merge into one file? Is this faster? Does it load faster or compile faster?

Merging files together makes deployment easier since there is less files to upload. It also permits more optimization since the compiler can do batch optimization on multiple web pages. However, when merging everything, the site has to be completely redeployed at every change (vs. only deploying the assemblies that have been updated).

Here is a rundown of the trade-offs of each options:

Merge all outputs to a single assembly: merging everything into one file makes the deployment easier since there is only one file to upload. Everything is compiled in the same package and this permit batch optimizations which makes page loads faster. However, if one part of the site changes, the whole website has to be uploaded again. If your website is not really big, that would be a good option.

Merge each individual folder output in its own assembly: makes deployment easier while avoiding the need to upload the whole site on every change. Only the folder containing the updated code needs to be recompiled and redeployed.

Merge all pages and control outputs to a single assembly: puts all the UI inside the same assembly without merging the code not related to UI. This lets you update the code not related to UI without having to redeploy the UI code.

Do not merge: the code files are compiled, but all the UI content is not precompiled. So a web page UI is compiled every time a user requests the page (minus the caching that might occur) and this makes page loads longer. However, since the UI is not compiled, if you need to edit one web page you can upload the new version of the specific file on the production server without having to recompile any part of the website. This is good for big websites that can't afford to be completely redeployed.

Do not merge. Create a separate assembly for each page and control: compiles every page into it's own assembly. You have the speed of precompiled code, but at the cost of preventing the compiler from doing batch optimizations on multiple pages (slightly longer page loads).

For more information about the merging and compilation of asp.net websites:

• ASP.NET Merge Tool (Aspnet_merge.exe)
• ASP.NET Compilation Tool (Aspnet_compiler.exe)

Answer 2

I just wanted to post here, because it might be relevant to other people. I had a large legacy project in ASP.NET Framework 4.7 running in Azure.

I had a lot of problems with the "live" compilation of pages on Azure. With a lot I mean really a lot. I.e. this. Sometimes I hit a page that wasn't precompiled and Azure seemed to exhaust all resources just on the compilation, bringing the whole application down. After a restart it took 8 (!!) minutes before it could handle the first hit. Local it was only like 30 seconds.

During Corona I finally had time to move to .NET Core - and all these problems instantly went away.

Despite that Microsoft says they will continue supporting .NET Framework for a long time, it is clear to me that Microsoft doesn't have any passion for that project anymore. The issues I had in combination with Azure were ridiculous.

I strongly recommend to migrate as soon as possible. Even for a large project it was less painful than I imagined beforehand.