Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Same project reference names have different casings in packages lock file #8581

Open
v-luzh opened this issue Sep 12, 2019 · 8 comments
Open

Comments

@v-luzh
Copy link

v-luzh commented Sep 12, 2019

Details about Problem

NuGet version: NuGet Client Dev\5.4.0.6233
VS Version: Master\29311.58
OS: Windows-10-Enterprise-19H1-04-05-2019

Detailed repro steps

  1. Create a solution with three .NET Core Class Library projects (named Lib1/Lib2/Lib3), make the project graph structure: Lib1 -> Lib2 -> Lib3 through “Add reference” context menu in Solution Explorer.
  2. Set property “RestorePackagesWithLockFile” to true in csproj file of Lib1.
  3. Restore the solution and look at the generated lock file “packages.lock.json”.

Expected

Same project reference names should have the same casings in lock file.

Actual

Same project reference names have different casings in lock file as below screenshot.
CasingIssue

Note

It started to repro from fixing of the bug 7840.

@zivkan
Copy link
Member

zivkan commented Sep 12, 2019

Point of clarification, the fact that the case is different in the file isn't really a concern (in my opinion at least). The issue is that restoring without the project changing can cause the lock file to change, just as in #7840.

@rrelyea
Copy link
Contributor

rrelyea commented Sep 16, 2019

@zivkan - i'm unclear with what we should do based on your statement. Is this good or bad behavior in the lock file? Why?

@zivkan
Copy link
Member

zivkan commented Sep 16, 2019

We should change the Lib3 that's listed as lib2's dependency to lowercase, so that the lock file doesn't change case in the following reproduction:

(cd to an empty directory)
dotnet new sln
dotnet new classlib -n ProjA
dotnet new classlib -n ProjB
dotnet new classlib -n ProjC
dotnet sln add proja\proja.csproj
dotnet sln add projb\projb.csproj
dotnet sln add projc\projc.csproj
dotnet add ProjA\ProjA.csproj reference PROJB\PROJB.csproj
dotnet add ProjB\ProjB.csproj reference PROJC\PROJC.csproj
echo '' > ProjA\packages.lock.json
dotnet restore –force-evaluate
copy ProjA\packages.lock.json ProjA\packages.lock.json.bak
dotnet restore –force-evaluate ProjA\ProjA.csproj
git diff ProjA\packages.lock.json ProjA\packages.lock.json.bak

@nkolev92 nkolev92 added Area:RestoreRepeatableBuild The lock file features Functionality:Restore Priority:3 Issues under consideration. With enough upvotes, will be reconsidered to be added to the backlog. Style:PackageReference Type:Bug labels Apr 8, 2020
@nkolev92 nkolev92 added Priority:2 Issues for the current backlog. and removed Priority:3 Issues under consideration. With enough upvotes, will be reconsidered to be added to the backlog. labels Nov 17, 2020
@heng-liu
Copy link
Contributor

Hi @nkolev92 , as @erdembayar and I are checking compatibility issues, may I know if the case change in the lock.json file will cause compatibility issue? Thanks!

@nkolev92 nkolev92 changed the title [Test Failure] Same project reference names have different casings in lock file Same project reference names have different casings in packages lock file Jan 23, 2021
@nkolev92
Copy link
Member

No, this is an old issue.

@AlexKeySmith
Copy link

Could this result in a NU1004 error? I'm attempting to diagnose why project A by itself restores ok, but when it is referenced by project B, then project A is reported as having changed dependencies. This is in dotnet 5.0.302

@nkolev92
Copy link
Member

nkolev92 commented Aug 2, 2021

@AlexKeySmith

Afaik, it shouldn't.

Would you mind creating an issue that we could have someone validate?

@AlexKeySmith
Copy link

Thanks @nkolev92 I realised my issue in the end was: #8465 but thanks for the response.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants