-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
NU1505: Duplicate 'PackageDownload' items warning is raised when the SDK uses PackageDownload to get packages. #24747
Comments
@nkolev92 The repro project: Netcoreapp.zip |
I am also hitting this issue while building WinForms designer repo locally: https://github.com/dotnet/winforms-designer. |
This is now fixed for the 6.0.4xx and 7.0.1xx branches, and will flow from those. |
Thanks for the quick fix! |
Is it possible this shipped in 17.3.0 Preview 1? I'm hitting the same symptoms which (and I don't like to exaggerate this) does make the preview pretty much unusable (downstream it can't load types, etc. after this). If this is in the 17.3 Preview 1 bits, recommend a preview with the fix go out asap. |
^ For anyone else finding this - workarounds for the moment are:
|
This is being hit by many members of the .NET team on the latest VS preview. Should we reactivate this bug? It's pretty clearly not fixed at this point or there is a new bug with the exact same symptoms :) |
@jaredpar the bug itself should be fixed, I think it's just that the SDK containing the fix hasn't flowed to the VS preview. I'm checking into that. |
The NuGet change raising these warnings is in 6.0.3xx. I should've caught it originally, but this might be a change that should be considered for that versions. |
@nkolev92 I only see 6.0.4xx and 7.0.100-preview4 merges associated with the NuGet.Client change, so I'm wondering how it's appearing in 6.0.300 at all? The latest 6.0.300 merge of NuGet.Client was for a 6.2.x version of NuGet.Client, so I'm unclear where the newer version was introduced. We should also be rolling forward to 6.0.400 SDK versions in future previews of VS 17.3 (per the versioning chart) so it should clear up then for early adopters. |
Too early in the morning for me apparently. The tags start with 6.3. |
I'm not sure on the urgency for this, but for what it's worth it cost me a lot of time today and for others that pinged me as well. A lot of builds have warnings as errors deeply embedded in there and we're all hacking at this passing in overrides for the properties to get by the current issue locally but for tomorrow I think it's easier for me to uninstall the preview completely. I haven't had to revert from a preview build in over a year now so this one is pretty serious IMO. I hope it makes a new preview build quickly for others hitting the issue - I think it warrants faster than a normal cadence from the number of reports I'm seeing. |
Hey folks, we have a good idea what happened and what the path forward is now. CauseNuGet in VS is independent of the NuGet shipped with the SDK. The NuGet in VS has gotten ahead of the SDK, and it includes the additional validation for duplicate PackageDownloads and PackageReferences. As a result, when the NuGet in VS interacts with a project that uses an SDK that contains the PackageDownload duplication bug, these errors appear for users. MitigationAll of these duplicate checks are guarded by an MSBuild condition. If you set ResolutionThe SDK will ship version 6.0.400 in VS 17.3, so it was just a matter of time until we did an insertion to that preview. We will accelerate our timeline and do the insertion early next week (after dotnet/installer#13827 merges). That will unblock the internal dogfood previews of 17.3 for internal Microsoft users. For the broader public, this will not be fixed until 17.3 Preview 2 is released, which should be roughly a month from now. |
@baronfel Thank you for the update! I personally haven't used the internal previews (because you can't update unless you're on the VPN - installer hangs) - I'm on the public preview here. For what it's worth, this issue is serious/blocking enough I hopped off the preview train this morning and did a full re-install to stable. I regularly work on a few dozen solutions, so to see how common this might be (I know I'm a small sample size), I tested 19 different repos from internal and open source and this bug breaks my ability to build every single one. I was kind of hoping this was worthy of a Preview 1.1 so I could continue on preview and help find these sorts of issues. Is it not affecting that many users overall for some reason? Or have not that many users grabbed latest preview? I'm doubting many people went to grab a nightly SDK but...maybe? |
@NickCraver It's not the ideal situation for sure! I'll see what levers I can pull for a faster fix on the public release, though. |
@baronfel Just upgraded to the official 17.3.0 release, but the issue still seems to exist while building one of our NetCore3.1 apps,
Right now, we set |
@kenans can you confirm what version of the SDK is in use for your projects? |
@baronfel Thanks for the quick reply. Our project has the SDK targeted to 5.0.406 in The issue only happened while building in Visual Studio. I assume the cause is NuGet in VS would not honor |
There's a(n overly-) complicated versioning matrix here, but I believe that's the root of the problem, yes - VS has NuGet tooling that's checking for duplicate PackageDownloads, coupled with using an SDK to build that's providing those duplicates. I believe that your problem would be resolved if you updated your SDK to the latest 6 series - is there some blocker preventing this? You can still build net5.0-targeting projects in a higher-SDK, if that was holding you back. |
@baronfel Thanks for the information! Will upgrade the SDK to net6 and try again. |
For anyone who runs into the same issue -- after upgrading the SDK version, the issue is resolved. |
Hello. Still having the problem for me using VS 2022 Pro 17.3.0 x64 Fr (up to date) : Installed applications :
The project is attached. I found no mention of these packages :( |
To which version? |
I still have the problem on Repro:
<ItemGroup>
<PackageDownload Include="minver-cli" Version="[4.1.0]" />
</ItemGroup>
<ItemGroup>
<PackageDownload Include="minver-cli" />
</ItemGroup>
|
Hi @lonix1 - it looks like your warning isn't raised by the SDK's use of PackageDownloads (which was the cause of this issue). Your issue seems to be because you're using different |
@baronfel I just hit what appears to be an invalid case for this warning. I have some packages conditionally added in my Here is an example: <Project>
<PropertyGroup>
<ImplicitUsings>enable</ImplicitUsings>
<Nullable>enable</Nullable>
<TreatWarningsAsErrors>true</TreatWarningsAsErrors>
<IsUnitTestProject>false</IsUnitTestProject>
<IsUnitTestProject>$(MSBuildProjectName.EndsWith('.UnitTests'))</IsUnitTestProject>
</PropertyGroup>
<ItemGroup Condition="$(IsUnitTestProject)">
<Using Include="FluentAssertions" />
<Using Include="FluentAssertions.Execution" />
<Using Include="NSubstitute" />
<Using Include="Xunit" />
<PackageReference Include="FluentAssertions" Version="6.7.0" />
<PackageReference Include="FluentAssertions.Analyzers" Version="0.17.2">
<PrivateAssets>all</PrivateAssets>
<IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
</PackageReference>
<PackageReference Include="Microsoft.NET.Test.Sdk" Version="17.2.0" />
<PackageReference Include="NSubstitute" Version="4.4.0" />
<PackageReference Include="NSubstitute.Analyzers.CSharp" Version="1.0.15">
<PrivateAssets>all</PrivateAssets>
<IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
</PackageReference>
<PackageReference Include="coverlet.collector" Version="3.1.2">
<IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
<PrivateAssets>all</PrivateAssets>
</PackageReference>
<PackageReference Include="xunit" Version="2.4.1" />
<PackageReference Include="xunit.runner.visualstudio" Version="2.4.5">
<IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
<PrivateAssets>all</PrivateAssets>
</PackageReference>
</ItemGroup>
</Project>
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>net6.0</TargetFramework>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="FluentAssertions" Version="6.7.0" />
<PackageReference Include="FluentAssertions.Analyzers" Version="0.17.2">
<PrivateAssets>all</PrivateAssets>
<IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
</PackageReference>
<PackageReference Include="MediatR" Version="10.0.1" />
<PackageReference Include="Microsoft.NET.Test.Sdk" Version="17.2.0" />
<PackageReference Include="NSubstitute" Version="4.4.0" />
<PackageReference Include="NSubstitute.Analyzers.CSharp" Version="1.0.15">
<PrivateAssets>all</PrivateAssets>
<IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
</PackageReference>
<PackageReference Include="xunit.core" Version="2.4.1" />
<PackageReference Include="xunit.runner.visualstudio" Version="2.4.5">
<IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
<PrivateAssets>all</PrivateAssets>
</PackageReference>
</ItemGroup>
</Project> Error:
It appears that the check is blindly looking at the presence of I added the above code to This was working fine until I updated Visual Studio to latest versions (I'm using 17.3.1 right now). It is possible it was introduced in 17.3.0 but I actually don't remember if I tried to build this project in between those 2 updates. Note that my example here has nothing to do with SDK packages... its throwing for explicit libraries that I have in the projects. I'll add the ignore flag for now until this is fixed. FAKE EDIT: While I was posting this, I decided to try to create a "minimal repro" in a test solution here. Weirdly enough, it actually took a while to happen and I don't know exactly what triggers it... I had to keep adding new projects, fiddling with the variables in |
The NU1504, NU1505 and NU1506 warnings were added in Visual Studio 17.3, NuGet.exe 6.3 and .NET SDK 6.0.400. All those tooling versions contain the same NuGet bits.
That shouldn't be the case as the check is running as part of a target that's run for each framework, so the conditions will be evaluated. I can't really say why you're seeing the intermittent behavior, but if you are seeing issues with things that aren't coming from the SDK (such as the NU1505 warnings for packages that are added by the SDK), I'd recommend filling a new issue. You can file issues with questions about NU1504 in the NuGet/Home repo. |
It'd be nice if this error message actually pointed to the file/source locations of the project/props/target files that are including these references. I hit this issue with the new warnings in our project, but I'm just referencing the SDK and such, so no idea where the extra package reference is coming from. Changed the PackageReference from |
See https://devblogs.microsoft.com/nuget/announcing-nuget-6-3-transitive-dependencies-floating-versions-and-re-enabling-signed-package-verification/#new-warnings-when-duplicate-packagereference-packageversion-or-packagedownload-are-found for info about increased warning level. Also see dotnet/sdk#24747 Not sure where the duplicate reference is coming from though...
See https://devblogs.microsoft.com/nuget/announcing-nuget-6-3-transitive-dependencies-floating-versions-and-re-enabling-signed-package-verification/#new-warnings-when-duplicate-packagereference-packageversion-or-packagedownload-are-found for info about increased warning level. Also see dotnet/sdk#24747 Not sure where the duplicate reference is coming from though...
See https://devblogs.microsoft.com/nuget/announcing-nuget-6-3-transitive-dependencies-floating-versions-and-re-enabling-signed-package-verification/#new-warnings-when-duplicate-packagereference-packageversion-or-packagedownload-are-found for info about increased warning level. Also see dotnet/sdk#24747 Not sure where the duplicate reference is coming from though...
Describe the bug
Recently NuGet added warnings for duplicate PackageReference/PackageDownload/PackageVersion items. Duplicate items could lead to an unpredictable behavior. You can learn about the motivation more in NuGet/Home#9864.
https://github.com/NuGet/Home/blob/dev/proposed/2022/duplicate-nuget-item-error-handling.md
NuGet added this in 6.0.400, so customers will start seeing this very soon.
To Reproduce
Originally filled in NuGet/Home#11720.
This was was discovered by the NuGet test team, @v-luzh Can you please post the csproj in question?
Why is this important?
NuGet will raise a warning when it sees duplicate items, and warning as errors could cause failures for customers.
Exceptions (if any)
Further technical details
dotnet --info
Latest main version of NuGet tooling will have this.
The text was updated successfully, but these errors were encountered: