dotnet / NuGet.BuildTasks

The build tasks used to pick up package content from project.lock.json.
MIT License
45 stars 61 forks source link

Reference metadata is not preserved if NuGet packages add duplicate Framework Reference #75

Open nkolev92 opened 4 years ago

nkolev92 commented 4 years ago

Metadata on Reference items is lost if the references are replaced by a reference from a NuGet package. For example, in a .NET 4.7.2 project with the following:

<ItemGroup>
    <Reference Include="System.Net.Http" Aliases="snh" />
    <PackageReference Include="System.Net.Http" Version="4.1.0" />
</ItemGroup>

And with the following code:

extern alias snh;
using System;

class Program
{
    static void Main(string[] args)
    {
        var client = new snh::System.Net.Http.HttpClient();
    }
}

Will fail to build, because NuGet will try to replace the Reference to System.Net.Http with the version of that DLL that comes from the NuGet package, and the Aliases information is lost. This happens here:

https://github.com/NuGet/NuGet.BuildTasks/blob/640c8e13a9b7ab6e86264a296638fbf3cc016ad1/src/Microsoft.NuGet.Build.Tasks/Microsoft.NuGet.targets#L209-L210

Conflict resolution comes along later and replaces the NuGet reference with a simple name reference again, but by that time the Aliases metadata is gone.

There are currently several ways that references can flow and get replaced, losing this metadata. I am planning to fix some of them in this PR: https://github.com/dotnet/sdk/pull/3331

The changes in that PR, together with deleting the referenced line from Microsoft.NuGet.targets, make this scenario work. That may be the right fix. It will result in multiple references to System.Net.Http (one a simple reference and one in the NuGet package), but ResolvePackageFileConflicts should choose the right one.

cc @dsplaisted