Sdk: unexpected/unnecessary `refs` directory in published output of ASP.NET Core application

[josalem]

Steps to reproduce

1. create new ASP.NET Core (.NET Framework) application template in Visual Studio
2. publish a release build
   

   Expected behavior

• The only DLLs included local to the .exe would be third-party libraries loaded as nugget packages

  Actual behavior

• There is a refs directory that contains many System.* DLLs, a copy of the application, and the DLL for Razor Tooling

• The refs directory can be removed and the application still runs and Razor pages still render
  

  Environment data

dotnet --info output:

.NET Command Line Tools (1.0.0-preview2-003121)

Product Information:
 Version:            1.0.0-preview2-003121
 Commit SHA-1 hash:  1e9d529bc5

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.14393
 OS Platform: Windows
 RID:         win10-x64

[eerhardt]

If you don't want this directory published, you can remove:

"preserveCompilationContext": true

from your project.json. But note that removing that setting may completely break your Razor compilation at runtime.

Closing as "by design".

@pranavkm

[pranavkm]

The expected behavior isn't necessarily correct. Razor compilation is attempting to use the same refs to compile the view at runtime as the ones that the application used. There's some fallback involved on desktop where it'll attempt to resolve under Program FilesReference Assemblies, but those aren't guaranteed to always exist and don't work for CoreCLR. So deleting the refs directory might result in runtime compilation failures. I'd recommend not deleting them if your application uses Views.

[softlion]

I agree with Josalem that there should not be duplicate files in this refs folder. But i agree that having reference assemblies there makes your app independant of the system configuration which is great as it wont break with system updates (but makes your app weak in security).

[Neutrino-Sunset]

I don't understand what's going on here.

"Razor compilation is attempting to use the same refs to compile the view at runtime as the ones that the application used."

This suggests that there are two separate sets of dependencies.

1. The application's dependencies.
2. The dependencies used by Razor to compile the view.

But isn't the code compiling the view contained in the Microsoft.AspNetCore assemblies? And aren't those assemblies loaded into the application's app domain? So don't they have the same dependencies as the application anyway, since they are part of the same application?

Also the assemblies in /refs don't even look like the actual assemblies they purport to be. E.g. Microsoft.CSharp.dll in/refs is 23k, except that no _real_ Micorsoft.CSharp.dll is actually 23k, the real ones are 1.1MB (Dotnet Core) and 472K (Dotnet Framework).

There is clearly more going on here than meets the eye and I need to understand it as I am designing our first ASP.Net Core application.

Is there a fuller more technical explanation of this somewhere or can someone here explain this please?

[pranavkm]

@Neutrino-Sunset - the two set of dependencies are

• Reference assemblies used to compile the application
• Binaries that are used to run the application.

If your application targets net451, it'll compile against the net451 reference assemblies. At runtime, it might end up using the net462 assemblies if that's installed on the machine since net451 -> net462 is an in-place upgrade. Razor compilation in Mvc Core attempts to use the same references that were used to compile the application - in this case the net451 ones.

Also the assemblies in /refs don't even look like the actual assemblies

Because they are reference assemblies, with just the API contract and no implementation.

[Neutrino-Sunset]

1) This is an ASP.Net Core (.Net Core) application. Therefore it is ASP.Net Core running on Dotnet Core. No Dotnet Framework. There should not be any Dotnet Framework involvement. Why would Dotnet Framework be involved at all? If ASP.Net Core did indeed have runtime dependence on the Dotnet Framework then how could it be cross platform?

2) The reference assembly behaviour you describe solves to the problem of targetting a version of Dotnet Framework which has been inplace upgraded to a later version, e.g. 4.0 -> 4.5. Dotnet Core does not have any inplace upgrades (versions 1.0.1 and 1.0.3 coexist in separate install directories), so why would reference assemblies and in-place upgrades be relevant for an ASP.Net Core application running on Dotnet Core?

[Neutrino-Sunset]

I could really use answers to these questions as no one being able to explain the project output is blocking our ability to proceed with ASP.Net Core. Is there somewhere else I could/should be asking these questions?

[eerhardt]

@Neutrino-Sunset - a thing to understand is that the assemblies your app compiles against are not the same assemblies your app loads at runtime. For starters, the compile-time assemblies just have the method signatures without any IL implementation. Which is why Microsoft.CSharp.dll in the refs folder is only 23k.

But an even bigger reason why your compile-time and runtime assemblies are different is because the actual types exist in different assemblies at compile-time than they do at runtime. For example, when you compile, System.Object is found in the System.Runtime.dll along with a bunch of other low-level system types. But at runtime, System.Object is actually contained in mscorlib.dll if you are running on the desktop framework, and in System.Private.CoreLib.dll if you are running on .NET Core.

You can think of the assemblies in the "refs" folder as the equivalent of header files in C++. You use these assemblies to compile code.

To guarantee that the assemblies used to compile Razor views at runtime match the assemblies used to compile your app, the refs folder is created and the build system copies the compile-time assemblies into the refs folder. As stated above, these assemblies are not duplicates of what the runtime loads when running your app. Some may have the same names, but what is contained inside of them is not the same information.

@weshaggard is working on publishing a document that explains reference assemblies much better than I can. One of us will post a link here when it is ready.

[eerhardt]

The document is up for PR:

https://github.com/dotnet/standard/pull/183

Thanks, @weshaggard.

[Neutrino-Sunset]

Thanks @eerhardt that's really useful.