Generated .deps.json for a resolved package should use path relative to published app layout instead of NuGet package layout

[elinor-fung]

Describe the bug

When building/publishing an app with package references, the generated .deps.json contains the package assets with paths based on the NuGet package layout. However, the actual built/published app does not use those paths. The assets are directly in the output directory (or a culture-specific sub-directory for resource assemblies).

The fact that this works is actually relying on a bug in the host: dotnet/runtime#3525

Fixing this (and then the bug in the host) is necessary for any scenario for customizing the published layout - for example, for self-contained runtime location or shared libraries experience:

• Specify runtime files location for self-contained apps runtime#3453
• Unable to specify a subdirectory for assembly loading #10366
• Support deploying multiple exes as a single self-contained set runtime#53834
• Enable shared libraries and runtimes for a software suite runtime#71282

To Reproduce

1. Add a PackageReference in a csproj:

   <ItemGroup>
     <PackageReference Include="Newtonsoft.Json" Version="13.0.3" />
   </ItemGroup>

2. Build/publish and inspect the generated .deps.json:

   "Newtonsoft.Json/13.0.3": {
     "runtime": {
       "lib/net6.0/Newtonsoft.Json.dll": {
         "assemblyVersion": "13.0.0.0",
         "fileVersion": "13.0.3.27908"
       }
     }
   }

3. Compare to the published app layout. The dependency is at <output_directory>/Newtonsoft.Json.dll, not <output_directory>/lib/net6.0/Newtonsoft.Json.dll, as the .deps.json indicates.

Exceptions (if any)

None

Further technical details

On latest .NET 10 builds

cc @dotnet/appmodel

[elinor-fung]

I think this is what puts the package path in the .deps.json:

sdk/src/Tasks/Microsoft.NET.Build.Tasks/DependencyContextBuilder.cs

Lines 697 to 705 in 4a81a96

	private RuntimeFile CreateRuntimeFile(ResolvedFile resolvedFile)
	{
	string relativePath = resolvedFile.PathInPackage;
	if (string.IsNullOrEmpty(relativePath))
	{
	relativePath = resolvedFile.DestinationSubPath;
	}
	return CreateRuntimeFile(relativePath, resolvedFile.SourcePath);
	}

sdk/src/Tasks/Microsoft.NET.Build.Tasks/DependencyContextBuilder.cs

Line 560 in 4a81a96

resourceAssemblies.AddRange(resourceFiles.Select(f => new ResourceAssembly(f.PathInPackage, f.Culture)));

[Forgind]

I'm a bit concerned by how bad a breaking change this might be. I know a lot of people rely on the deps.json, and I'd be concerned that other users might expect the path to stay as it is and start failing to find it. Do you have a sense for that, or some way we can test it?

[elinor-fung]

I don't have a good sense, but I'd expect reading .deps.json to go through DependencyContextJsonReader or DependencyContextLoader: https://grep.app/search?regexp=true&q=DependencyContextLoader%7CDependencyContextJsonReader

Skimming through the first couple, they just take the filename from the RuntimeFile path.

A case I could maybe see that would work with the NuGet package path, but not the actual publish path:

1. Explicitly reading the .deps.json for some assembly
2. Assembly is not published to copy its dependencies locally
3. Checking the paths relative to a NuGet cache

For that, could we keep the package path for (2)? Since the SDK would know if each asset is being copied to the output when generating the .deps.json?

If it seems too concerning, another possibility could be to introduce a property that is the publish path / DestinationSubPath, so the existing value doesn't change:

"Newtonsoft.Json/13.0.3": {
  "runtime": {
    "lib/net6.0/Newtonsoft.Json.dll": {
      "assemblyVersion": "13.0.0.0",
      "fileVersion": "13.0.3.27908",
      "localPath": "Newtonsoft.Json.dll"
    }
  }
}

[marcpopMSFT]

Triage: Let's do it in 10 and mark it as a breaking change. That path doesn't exist in the output directory and is only in the nuget package? Seems very niche to have someone read the deps and use that to look at the nuget package location.

[dotnet-policy-service]

Refer to the .NET SDK breaking change guidelines