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

[Bug]: RAR falsely claims an assembly reference has a higher version #8476

Closed
AArnott opened this issue Feb 21, 2023 · 1 comment
Closed
Labels
bug needs-triage Have yet to determine what bucket this goes in.

Comments

@AArnott
Copy link
Contributor

AArnott commented Feb 21, 2023

Issue Description

All references are to NuGet.VisualStudio.Contracts 17.2.0.0. The binding redirect is to 17.6.0.0. RAR false claims that another referenced assembly references 17.6.0.0 when in fact it only references 17.2.0.0:

Note the > marked lines below.

Warnings
    C:\Program Files\Microsoft Visual Studio\2022\IntPreview\MSBuild\Current\Bin\amd64\Microsoft.Common.CurrentVersion.targets(2352,5): warning MSB3277: Found conflicts between different versions of "NuGet.VisualStudio.Contracts" that could not be resolved. [C:\VS\src\vsproject\PackageAndDeploy\DeploymentService.UnitTests\DeploymentService.UnitTests.csproj]
        There was a conflict between "NuGet.VisualStudio.Contracts, Version=17.2.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" and "NuGet.VisualStudio.Contracts, Version=17.6.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a".
        "NuGet.VisualStudio.Contracts, Version=17.2.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" was chosen because it was primary and "NuGet.VisualStudio.Contracts, Version=17.6.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" was not.
        References which depend on "NuGet.VisualStudio.Contracts, Version=17.2.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" [C:\_nugetpackages\nuget.visualstudio.contracts\17.2.0\lib\netstandard2.0\NuGet.VisualStudio.Contracts.dll].
            C:\_nugetpackages\nuget.visualstudio.contracts\17.2.0\lib\netstandard2.0\NuGet.VisualStudio.Contracts.dll
                Project file item includes which caused reference "C:\_nugetpackages\nuget.visualstudio.contracts\17.2.0\lib\netstandard2.0\NuGet.VisualStudio.Contracts.dll".
                    C:\_nugetpackages\nuget.visualstudio.contracts\17.2.0\lib\netstandard2.0\NuGet.VisualStudio.Contracts.dll
>       References which depend on "NuGet.VisualStudio.Contracts, Version=17.6.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" [].
>           C:\VS\out\binaries\x86chk\bin\netsdk\vsproject\DeploymentService\net472\Microsoft.VisualStudio.TailoredProjectServices.dll
                Project file item includes which caused reference "C:\VS\out\binaries\x86chk\bin\netsdk\vsproject\DeploymentService\net472\Microsoft.VisualStudio.TailoredProjectServices.dll".
                    C:\VS\out\binaries\x86chk\bin\netsdk\vsproject\DeploymentService\net472\Microsoft.VisualStudio.TailoredProjectServices.dll

Full binlog: msbuild-RAR-false-assembly-reference.binlog

I realize I have a problem in that there is no 17.6.0.0 assembly to reference, yet the binding redirects want it. I'll work on that. But the RAR warning is misleading and had I not already known the problem, I might have wasted a lot of time chasing the wrong problem, so I wanted to share here.

Steps to Reproduce

In the VS repo, run the following steps:

git checkout f238cf001782293096a220d752c82977a6b2a8b4
.\retail.ps1
bm /r src\vsproject\PackageAndDeploy\DeploymentService.UnitTests

Expected Behavior

RAR would be satisfied that all references are consistently to 17.2.0.0.
Maybe it would warn that the binding redirect is to 17.6.0.0, which is suspicious given the assembly references.

Actual Behavior

RAR warns that some assembly references are to 17.6.0.0, which is simply untrue.

Analysis

No response

Versions & Configurations

MSBuild version 17.6.0-preview-23112-04+dba9b2343 for .NET Framework
17.6.0.11204

@AArnott AArnott added bug needs-triage Have yet to determine what bucket this goes in. labels Feb 21, 2023
@rainersigwald
Copy link
Member

Thanks and sorry for the noise. I think this bad experience is a combination of #4757 and #7412.

@rainersigwald rainersigwald closed this as not planned Won't fix, can't repro, duplicate, stale Feb 21, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug needs-triage Have yet to determine what bucket this goes in.
Projects
None yet
Development

No branches or pull requests

2 participants