19

What is the purpose of *deps.json file in .NET Core? What is the reason to store references in such file and not in assembly manifest(as in standalone .NET Framework)?

Using Ildasm i checked that assembly manifest doesn't contain entries for these dependecies after dotnet build command.

But it has entries after dotnet publish command.

Roman Roman
  • 617
  • 1
  • 9
  • 16
  • 3
    Yeah, you don't want to look too close, scary stuff that hopefully it is not going to last much longer. This used to live in project.json but isn't really gone yet. It is a side-effect of the way they tackled .NETCore v1, they broke up the framework assemblies in lots and lots of tiny ones. On the theory that it would be easier to port them to MacOS and the many Linux flavors and make changes while working on it. Plan is to go back to large ones, not sure when it is going to be executed. – Hans Passant Oct 07 '17 at 16:34
  • @Hans_Passant Are there any differences with v3 of .NetCore, or does it still need these `.deps.json' files? – intrepidis Sep 15 '20 at 19:34

1 Answers1

17

The .deps.json file contains metadata about the assemblies referenced by the built assembly and the locations to search for them as well as information about the compilation options used.

This information is read by the native component (corehost) that loads and configures the runtime. When a referenced assembly needs to be loaded, the host will use the information in this file (as well as any runtimeconfig.json/runtimeconfig.dev.json) to locate the correct assembly to load.

This information is used in other places as well. For example ASP.NET Core's Razor view compilation also uses it to pass the correct references and configuration to the generated code. And unit test hosts also need to use the information in this file when a unit test library is loaded into the test host. The managed API to read and write this file is available in the Microsoft.Extensions.DependencyModel NuGet package.

Martin Ullrich
  • 94,744
  • 25
  • 252
  • 217
  • I read article about corehost, and as i understand it fully ignores assembly manifest. Assemblies to load = assemblies in directory + assemblies in .deps file Am I correct? – Roman Roman Oct 08 '17 at 10:40
  • Also in my Mac all base libraries are loaded from /usr/local/share/dotnet/shared This path is not described anywhere. – Roman Roman Oct 08 '17 at 10:59
  • Yes the assemblies are resolved whenever the CoreCLR needs an assembly that is referenced by the IL it has to work with. The same is true for the full CLR. The manifest part is more important for non-.NET / "native" DLLs because in contrast to IL, native code doesn't contain assembly references so the metadata needs to tell the linker which files to load at startup so that all used symbols are resolved. – Martin Ullrich Oct 08 '17 at 11:55
  • Of course, but how does it know the assembly where the type is? For my understanding, in full .NET at startup it reads main assembly manifest and loads a metadata part for all referenced assemblies. And then, in runtime, when some type is referenced, it knows the assembly where it is from and loads this assembly. – Roman Roman Oct 09 '17 at 18:30
  • a type is always referenced using the assembly name. For example `new DirectoryEntry();` would become `newobj instance void [System.DirectoryServices]System.DirectoryServices.DirectoryEntry::.ctor()` in IL and the CLR would search for an assembly matching `System.DirectoryServices`. – Martin Ullrich Oct 09 '17 at 18:58
  • When I create an empty lambda function via AWS tool kit for visual studio , I don't see this file. so how come it works? I do see it in publish , but when I want to test it in visual studio via mock tool , then I get an error : https://stackoverflow.com/questions/56619863/net-core-2-1-lambda-function-does-work-while-in-2-2-it-doesnt – Royi Namir Jun 16 '19 at 15:13