RestoreLockedMode: Unexpected NU1004 when ProjectReference refers to a project with custom AssemblyName

[livarcocc]

From @patrikbeno on March 17, 2019 12:23

Steps to reproduce

<!-- ClassLib1/ClassLib1.csproj -->
<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>netcoreapp2.2</TargetFramework>
    <!-- following line breaks RestoreLockedMode=true -->
    <AssemblyName>CustomName</AssemblyName>
  </PropertyGroup>
</Project>

<!-- ClassLib2/ClassLib2.csproj -->
<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>netcoreapp2.2</TargetFramework>
  </PropertyGroup>
  <ItemGroup>
    <ProjectReference Include="..\ClassLib1\ClassLib1.csproj" />  
  </ItemGroup>
</Project>

$ cd ClassLib2
$ dotnet restore -f --use-lock-file
$ dotnet restore -f --locked-mode

Expected behavior

dotnet restore -f --locked-mode completes without error.

Actual behavior

ClassLib2/ClassLib2.csproj : error NU1004: The packages lock file is inconsistent with the project dependencies so restore can't be run in locked mode. Please disable RestoreLockedMode MSBuild property or pass explicit --force-evaluate flag to run restore to update the lock file.
Restore failed in 56.35 ms for /solution/ClassLib2/ClassLib2.csproj.

Environment data

dotnet --info output:

tested in latest dotnet/core/sdk:2.2-alpine docker image

.NET Core SDK (reflecting any global.json):
 Version:   2.2.105
 Commit:    7cecb35b92

Runtime Environment:
 OS Name:     alpine
 OS Version:  3.8
 OS Platform: Linux
 RID:         linux-musl-x64
 Base Path:   /usr/share/dotnet/sdk/2.2.105/

Host (useful for support):
  Version: 2.2.3
  Commit:  6b8ad509b6

Copied from original issue: dotnet/cli#10988

[livarcocc]

From @patrikbeno on March 17, 2019 19:30

also tested in latest 3.0 preview:

.NET Core SDK (reflecting any global.json):
 Version:   3.0.100-preview3-010431
 Commit:    d72abce213

Runtime Environment:
 OS Name:     alpine
 OS Version:  3.9
 OS Platform: Linux
 RID:         alpine.3.9-x64

[jeffkl]

@nkolev92 I think the issue is that the lock file is writing the project reference Id:

https://github.com/NuGet/NuGet.Client/blob/dev/src/NuGet.Core/NuGet.Commands/PackagesLockFileBuilder.cs#L76

But the verification uses the project file name:

https://github.com/NuGet/NuGet.Client/blob/dev/src/NuGet.Core/NuGet.ProjectModel/ProjectLockFile/PackagesLockFileUtilities.cs#L99

[jeffkl]

One workaround is to rename your project to the same as <AssemblyName>. This can be painful for large repositories. I have a potential fix here: NuGet/NuGet.Client@c7a02ff. It uses the file name when writing the lock file to keep things consistent.

[jeffkl]

/cc @zivkan to get this on your radar

[anangaur]

As discussed, I think we should give preference in the following order:

1. PackageId
2. AssemblyName
3. Project file name

I have no pref between 1 or 2, but I guess we should respect a name specifically mentioned in the csproj as either PackageId or AssemblyName.

[nkolev92]

What @anangaur is referring to more specifically is the following:
https://github.com/NuGet/NuGet.Client/blob/dev/src/NuGet.Core/NuGet.Build.Tasks/NuGet.targets#L633-L637
We are not changing that order.

Basically what we are debating is given a project with a custom assembly name, does the lock file contain:
Lib1 -> Lib2 (CustomName)

{
  "version": 1,
  "dependencies": {
    ".NETFramework,Version=v4.7.2": {
      "CustomName": {
        "type": "Project"
      }
    }
  }
}

or

{
  "version": 1,
  "dependencies": {
    ".NETFramework,Version=v4.7.2": {
      "Lib2": {
        "type": "Project"
      }
    }
  }
}

If you look at the assets file you will see CustomName as the unique identifier.

I am ok with either approach and both are the same complexity.

[nkolev92]

Discussed internally, we will preserve the assembly name/package id representation as it guarantees uniqueness in the package graph.

[bergbria]

@nkolev92 - Thanks for fixing this! I see this is part of the 5.1 milestone. How far away would you guess that release is? Once it is released, how long until the fix makes it into the .net sdk?

This will prevent many people in my team from migrating to .net core/standard (or even packagereferences) since we have a hard requirement for lock file usage.

[nkolev92]

5.1 is 16.1 and matches 2.2.300, 2.1.700 of the SDK. The stable release should happen in the 2nd quarter of May.

However, this fix should make it in preview 3 of all respective products.

[bergbria]

@nkolev92 - the issue is not fixed in sdk version 2.2.300. See
this automated repro for proof.

Sample output:

========================== Restoring dll with custom assembly name ==========================
  Restore completed in 126.15 ms for C:\Users\bberger\Desktop\restore_assemblyName_repro\dll\dll.csproj.
========================== Restoring exe with ProjectReference. Succeeds ==========================
  Restore completed in 21.52 ms for C:\Users\bberger\Desktop\restore_assemblyName_repro\dll\dll.csproj.
  Restore completed in 134.37 ms for C:\Users\bberger\Desktop\restore_assemblyName_repro\exe\exe.csproj.
========================== Restoring exe with --locked-mode. Fails even though the lock file was just generated ==========================
D:\o3\Build\OfficeNugetInit\gen\.versionless\office.dotnetsdkbootstrapper\sdk\sdk\2.2.300\NuGet.targets(121,5): error NU1004: The packages lock file is inconsistent with the project dependencies so restore can't be run in locked mode. Please disable RestoreLockedMode MSBuild property or pass explicit --force-evaluate flag to run restore to update the lock file. [C:\Users\bberger\Desktop\restore_assemblyName_repro\exe\exe.csproj]
  Restore failed in 34.13 ms for C:\Users\bberger\Desktop\restore_assemblyName_repro\exe\exe.csproj.
  Restore completed in 126.3 ms for C:\Users\bberger\Desktop\restore_assemblyName_repro\dll\dll.csproj.```

[nkolev92]

@bergbria
I'll take a look.

[nkolev92]

I can repro it.

This should only be an issue if there's ATF enabled in the project (which is by default in .NET Core SDK).

The equality check runs into an unexpected situation.
Created and self-assigned #8187

[nkolev92]

Note that it has nothing to do with the AssemblyName but rather ATF.