Why do .NET 5 projects create two identically named DLLs, one in the main binaries folder and one in a refs subfolder, in addition to the EXE?

Question

If I build a .NET 5 project that produces an executable, I get the following files:

• bin/Debug/net5.0-windows/MyProject.exe
• bin/Debug/net5.0-windows/MyProject.dll
• bin/Debug/net5.0-windows/ref/MyProject.dll

Why are all these three files created? Older versions of .NET just generated an EXE. Why do we need two identically named DLLs in different folders to go along with the EXE?

Answer 1

MyProject.exe:
Platform-specific executable generated for convenience so you don't need to write dotnet MyProject.dll to start application.
According to documentation .NET SDK 2.1 was not producing it.

MyProject.dll:
Main application dll - cross-platform dll with entry point.
You have the option to put it inside platform-specific .exe by using Single file deployment and executable https://learn.microsoft.com/en-us/dotnet/core/deploying/single-file

ref/MyProject.dll:
Dll for some runtime compilation by other tools. Described in @Andrew's answer. Generation can be disabled by the compiler option.

Summary
With cross-platform .NET Core you can distribute your application in many different ways but the price comes with new levels of indirections and new compiler options.

Answer 2

Its normally used where some assemblies are used during Runtime .

These are used to speed up the build process and contain stripped down information relating to other reference files, really just an interface so the project dependencies are not rebuilt every time where no change is necessary. See Reference Assemblies. If the project doesn't include any other assemblies there is little benefit.

The dependencies are listed in [ProjectName].deps.json

You can add this to the project file to avoid generating them

    <PropertyGroup>
    <ProduceReferenceAssembly>false</ProduceReferenceAssembly>
  </PropertyGroup>

They are more useful with Razor views as Razor views are compiled at runtime and use this refs folder. The folder can be removed when projects are published. Even with pre .net core the project contained a list of assemblies to be used by the views.

I found a more official source here: it is a QA from an MS devblog (although it applies to .net core)

Question: When you publish ASP.NET Core web application that uses CodeGen applications, it creates a refs folder. What is this used for?

Answer: The “refs” folder is created when the msbuild property is set to true. This is required for applications that need to preserve the assemblies that were used during compilation, typically because they need to do some compilation at runtime as well, e.g. to compile Razor views.

We set that to “true” by default when the project uses the Microsoft.NET.Sdk.Web (which ASP.NET Core projects should always be doing). However, our Razor packages include a target that during “dotnet publish” pre-compiles the Razor views and then removes the ref folder from the output. This behavior is enabled when the Microsoft.AspNetCore.Mvc.Razor.ViewCompilation package is referenced. It can be further controlled by setting the < MvcRazorCompileOnPublish> property. The Microsoft.AspNetCore.All package pulls in this package so that behavior is enabled by default for all new projects.

In short, if you have Razor views in your application, we recommend configuring the project to compile them during publish, by referencing the Microsoft.AspNetCore.Mvc.Razor.ViewCompilation package. This will improve startup time and remove the “refs” folder from our publish output for you.

Devblog why ref folder?