NuGet updates #105
NuGet updates #105
Conversation
bording
force-pushed
the
nuget-updates
branch
from
579ade7
to
95cbb92
Compare
| <PropertyGroup> | ||
| <AutomaticVersionRangesEnabled Condition="'$(AutomaticVersionRangesEnabled)' == '' And '$(Configuration)' == 'Debug'">false</AutomaticVersionRangesEnabled> | ||
| <AutomaticVersionRangesEnabled Condition="'$(AutomaticVersionRangesEnabled)' == '' And '$(IsPackable)' == 'false'">false</AutomaticVersionRangesEnabled> | ||
| <AutomaticVersionRangesEnabled Condition="'$(AutomaticVersionRangesEnabled)' == '' And '$(ManagePackageVersionsCentrally)' == 'true'">false</AutomaticVersionRangesEnabled> | ||
| <AutomaticVersionRangesEnabled Condition="'$(AutomaticVersionRangesEnabled)' == ''">true</AutomaticVersionRangesEnabled> | ||
| </PropertyGroup> |
There was a problem hiding this comment.
Question: As I understand it, the new setting will be enabled by default. How we will disable it?
It will be enough to add <AutomaticVersionRangesEnabled>true</AutomaticVersionRangesEnabled> to the Custom.Build.props file on the repo?
There was a problem hiding this comment.
It needs to be set to false, not true, but otherwise, yes. It can be set in Custom.Build.props to disable it globally, or in an individual project as needed.
| <AutomaticVersionRangesEnabled Condition="'$(AutomaticVersionRangesEnabled)' == ''">true</AutomaticVersionRangesEnabled> | ||
| </PropertyGroup> | ||
|
|
||
| <UsingTask TaskName="ConvertToVersionRange" TaskFactory="RoslynCodeTaskFactory" AssemblyFile="$(MSBuildToolsPath)\Microsoft.Build.Tasks.Core.dll" > |
There was a problem hiding this comment.
Spacing is wonky on this block, 1 on the start element, 2 on the end, no indentation for Task. Is there a reason to have the rest of the file left-aligned despite the wrapping Project element?
|
|
||
| <UsingTask TaskName="ConvertToVersionRange" TaskFactory="RoslynCodeTaskFactory" AssemblyFile="$(MSBuildToolsPath)\Microsoft.Build.Tasks.Core.dll" > | ||
| <Task> | ||
| <Code Source="$(MSBuildThisFileDirectory)ConvertToVersionRange.cs" /> |
There was a problem hiding this comment.
I would consider finding a name for a subfolder to put this file and the C# file in. The more I think about it the more I think people are going to be very confused seeing a C# file in the src folder, and may try to move/remove it, leading to resync PRs. I know targets is a poor choice because of https://github.com/Particular/NServiceBus.RabbitMQ/tree/master/src/targets but what about packaging or packaging-targets? Long term the strong name keys could also move into such a folder to have them more out of the way, but that's obviously a much bigger change that would also require cleanup. Something to think about, anyway.
| </Task> | ||
| </UsingTask> | ||
|
|
||
| <Target Name="ConvertProjectReferenceVersionsToVersionRanges" AfterTargets="_GetProjectReferenceVersions" Condition="'$(AutomaticVersionRangesEnabled)' == 'true'"> |
There was a problem hiding this comment.
Since it's touching private targets, have you tried this with the net9 SDK, since we're only a few weeks from that?
| </Task> | ||
| </UsingTask> | ||
|
|
||
| <Target Name="ConvertProjectReferenceVersionsToVersionRanges" AfterTargets="_GetProjectReferenceVersions" Condition="'$(AutomaticVersionRangesEnabled)' == 'true'"> |
There was a problem hiding this comment.
I am just curious, what is an example of a project reference with a version?
| continue; | ||
| } | ||
|
|
||
| var privateAssets = reference.GetMetadata("PrivateAssets"); |
There was a problem hiding this comment.
This works regardless of if it's as an XML attribute or sub-element, correct?
| } | ||
|
|
||
| var version = reference.GetMetadata(VersionProperty); | ||
| var match = Regex.Match(version, @"^\d+"); |
There was a problem hiding this comment.
Given how the code is being included in MSBuild, can it use the Regex source generators?
|
|
||
| var nextMajor = Convert.ToInt32(match.Value) + 1; | ||
|
|
||
| var versionRange = $"[{version}, {nextMajor}.0.0)"; |
There was a problem hiding this comment.
Since we don't have to type all these anymore, is there a way to make a range that accounts for the brokenness of NuGet version ranges with respect to prereleases of the next major? I didn't re-read that thread again, but would [7.0.0, 8.0.0-0) work and is it worth it to try doing that? Or would that just result in a bunch of weird packages that would be super-odd if Microsoft ever decides to fix NuGet/Home#6434 ?
This PR makes changes to prepare for handling vulnerabilities reported by NuGet's security audit feature.
NuGetAuditModeinDirectory.Build.propstoallto match the default value coming in the 9.0.100 SDK. This value can be set inCustom.Build.propsto override the value globally, something we might end up needing to do on older release branches, for example.PackageReferenceversions and to eliminate the need for duplicate references in test projects, the automatic version ranges feature added here will automatically create the version ranges for any packages that are created.dependebot.ymlmakes it work again, so for now we'll stick with that.