10

What is the point of setting "No Managed Code" .NET CLR version for an IIS Asp.NET Core application pool?

No Managed Code for .NET CLR version

Documentation says that

ASP.NET Core runs in a separate process and manages the runtime. ASP.NET Core doesn't rely on loading the desktop CLR. Setting the .NET CLR version to No Managed Code is optional.

Since it is optional, what are the drawbacks of keeping the default v4.0? Why the documentation explicitly instructs to set it to "No Managed Code"? It's not very clear whether there are performance concerns around this particular configuration.

natenho
  • 5,231
  • 4
  • 27
  • 52
  • 2
    Keeping ASP.NET 4.x means IIS worker process will still try to load ASP.NET related supporting libraries (aspnet_isapi.dll or webengine4.dll) into memory, while your ASP.NET Core apps won't use them at all. That extra memory usage should be avoided. – Lex Li Mar 09 '18 at 03:25
  • @LexLi: Please post that as an answer. – Chris Pratt Mar 09 '18 at 13:34

1 Answers1

11

When you specify .NET CLR version as 4.0 for an application pool, IIS loads into its worker processes some ASP.NET supporting libraries (like aspnet_isapi.dll for classic pipeline mode, and webengine4.dll for integrated mode). Such increases memory usage and attack surface, and might also have other impact.

Therefore, if you only run non-ASP.NET 4.x apps (PHP, ASP.NET Core and so on), you can set "No Managed Code" to remove all the troubles.

Lex Li
  • 60,503
  • 9
  • 116
  • 147
  • I see, but..does it actually load that supporting libraries? You wrote "IIS tried to load". I'll run some tests to better understand it... My point is that should be transparent, but instead, you know, it's more like toggling bad/good modes with no functional advantage. – natenho Mar 10 '18 at 15:39