Closed stevenvolckaert closed 1 year ago
The SDK already supports the Microsoft.Build.CentralPackageVersions
SDK/package mechanism for doing this. It detects and omits the version numbers for package references based on the property UsingMicrosoftCentralPackageVersionsSdk
.
If you add this (set to true) it should work as expected for the NuGet intrinsic system too.
The SDK could be updated to check for the ManagePackageVersionsCentrally
property too, and I will look at doing that in a future update.
<Project>
<PropertyGroup>
<ManagePackageVersionsCentrally>true</ManagePackageVersionsCentrally>
<UsingMicrosoftCentralPackageVersionsSdk>true</UsingMicrosoftCentralPackageVersionsSdk>
</PropertyGroup>
<ItemGroup>
<PackageVersion Include="Microsoft.Net.Compilers.Toolset" Version="4.3.0" />
<PackageVersion Include="Microsoft.CodeDom.Providers.DotNetCompilerPlatform" Version="3.6.0" />
</ItemGroup>
</Project>
I confirm this works, thank you for your support @CZEMacLeod!
The release of NuGet 6.2.0, released with Visual Studio 2022 17.2, makes it possible to manage the versions of package references centrally in a single (or multiple, if one would wish)
Directory.Packages.props
file.See Central Package Management (CPM) on Microsoft Docs.
I've been migrating some of our projects to use CPM. Today I tried to migrate our first
Sdk="MSBuild.SDK.SystemWeb/4.0.82"
project, but I'm getting a NU1008 error:I presume MSBuild.SDK.SystemWeb would need to be updated to support this scenario?
Basically, when a
Directory.Packages.props
file is defined / used, theVersion
attribute on packagesMicrosoft.CodeDom.Providers.DotNetCompilerPlatform
andMicrosoft.Net.Compilers.Toolset
should either be removed or be updated toVersionOverride
.Could this be considered for a future, perhaps for the next release?
For the meantime, I could quite easily workaround this issue by setting property
ExcludeASPNetCompilers
totrue
:So supporting CPM is by no means an urgent feature request.
Thank you!