Closed kabua closed 1 year ago
One point of interest. In the newer versions of VS 2022, we have noticed that if a project contains a ProjectReference
element, then the solution must include that project as well. Therefore, we have had to add all the projects from both the Empower.Configuration
framework and the Smartwebs
framework to the Empower
framework solution.
We are guessing, to fix this issue, we may have to add the conditional ProjectReference
logic to the Empower.Configuration
project as well.
But the real frustration is that the errors are complaining, not that we are referencing the same project both as a ProjectReference
and as a PackageReference
but that nuget
can't resolve the 3rd party packages that this project references.
IOWs, Smartwebs.System
is referencing several 3rd party packages; it's these packages that nuget
is failing to resolve correctly. Thus we have 410 errors which all look like this:
NU1106 Unable to satisfy conflicting requests for 'Microsoft.Windows.Compatibility':
Microsoft.Windows.Compatibility (>= 6.0.0) (via project/Empower.Configuration 10.0.0-a003-Debug),
Microsoft.Windows.Compatibility (>= 6.0.0) (via project/Smartwebs.System 10.0.0-a005-Debug)
Framework: (.NETFramework,Version=v4.8)
Empower.Common C:\Sw\V9\EmpowerCore\Src\Frameworks\Empower\Empower.Common\Empower.Common.csproj 1
Notice, from the csproj files stated above, that both frameworks are referencing exactly the same package: Microsoft.Windows.Compatibility.6.0.0
and this is true for all the other reference packages.
Yep.
Changing the Empower.Configuration.csproj
from:
<ItemGroup>
<PackageReference Include="Smartwebs.System" Version="10.0.0-a005-Debug" />
</ItemGroup>
to:
<ItemGroup Condition="'$(Configuration)'=='Release' or '$(swPack)'=='1'">
<PackageReference Include="Smartwebs.System" Version="10.0.0-a005-Debug" />
</ItemGroup>
<ItemGroup Condition="'$(Configuration)'!='Release' and '$(swPack)'!='1'">
<ProjectReference Include="..\..\Smartwebs\Smartwebs.System\Smartwebs.System.csproj" />
</ItemGroup>
Solved this issue for this one project but we are still seeing NU1106 Unable to satisfy conflicting requests
in other projects.
Thank for the detailed issue description. May be a duplicate of https://github.com/dotnet/sdk/issues/12473 one and the root cause mentioned here appears to be same as https://github.com/dotnet/sdk/issues/12473#issuecomment-669515050.
How about publishing symbol packages (.snupkg) https://learn.microsoft.com/nuget/create-packages/symbol-packages-snupkg?
Will the restore succeed if we delete obj\*
(mainly project.assets.json) files for all projects after changing the configuration from debug
to release
or vice versa?
@kabua slightly orthogonal, but when a project is packed, all ProjectReference
s get converted into dependencies, just as PackageReference
s do. Is there some other reason you're switching between package & project references? Many customers I've helped didn't know about this, and were able to simplify their project file, removing the conditions and always using the project references.
Also for what it's worth, we have documented: https://learn.microsoft.com/en-us/nuget/consume-packages/package-references-in-project-files#adding-a-packagereference-condition
You can use a condition to control whether a package is included, where conditions can use any MSBuild variable or a variable defined in the targets or props file. However, at presently, only the TargetFramework variable is supported.
However, that's no excuse for restore to crash with a stack trace. Error scenarios should be reported with an NU*
code and a clean exit.
@kartheekp-ms We are using the new symbol packages. I haven't tried deleting obj\*
between debug
and release
, I will see if I can try that sometime next week.
@zivkan
when a project is packed, all
ProjectReference
s get converted into dependencies, just asPackageReference
s do
Oh my! I did not know that. Thanks for the heads-up, I will try it out.
This issue has been automatically marked as stale because we have not received a response in 14 days. It will be closed if no further activity occurs within another 14 days of this comment.
Currently working on implementing these ideas into our code.
Team Triage: Closing for now, let us know if this needs to be reopened if the suggested solutions don't work.
I have now this issue taking place in a build of Azure DevOps: https://dev.azure.com/faburaya/Reusable.NET/_build/results?buildId=116&view=logs&j=12f1170f-54f2-53f3-20dd-22fc7dff55f9&t=86dd5fa6-f51e-57a1-6dd4-575fd75fc7ef
Having this issue too.
NuGet Product Used
Visual Studio Package Management UI
Product Version
VS Pro 2022 version 17.3.4
Worked before?
It did work in an earlier version VS2022 but don't remember which one.
Impact
I'm unable to use this version
Repro Steps & Context
Back Ground We expose our internal frameworks as NuGet packages to our development teams. But debugging these frameworks as multiple NuGet packages is very challenging, therefore, we use
ProjectReferences
and conditional build settings to manage these challenges.Issue We have a project called
Empower.Common
(which is part of a larger framework), which depends onEmpower.Configuration
. BothEmpower.Common
andEmpower.Configuration
depends onSmartwebs.System
.When building in debug mode, we want to reference these projects as
ProjectReferences
, but in release mode or during the package building step, we want to reference these packages usingPackageReference
. This arrangement worked in VS2019 and earlier versions of VS 2022.Now, we get 410 Errors just from this one project. If we reload the other 6 projects, we are seeing 2,488 errors.
We are also seeing this error,
The "GenerateDepsFile" task failed unexpectedly
becauseAn item with the same key has already been added.
What key has already been added?Here's the full error message:
Potential Cause We think the issue has to do with
ProjectReference
andPackageReference
not playing nicely together. Here are the relationships: Empower.Common -> (ProjectReference
) Empower.Configuration Empower.Common -> (ProjectReference
) Smartwebs.SystemEmpower.Configuration -> (
PackageReference
) Smartwebs.System (v10.0.0-a003-debug)Therefore,
Empower.Common
is getting majorly confused as to how to resolve all package references found inSmartwebs.System
project and fromSmartwebs.System
package. Even though they both reference the same folder location and source code.Here are the three project files (source file references excluded):
Empower.Common.csproj
Empower.Configuration.csproj
Smartwebs.System.csproj
Verbose Logs