-
Notifications
You must be signed in to change notification settings - Fork 132
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
Add Humanizer.Core #1895
Add Humanizer.Core #1895
Conversation
df24027
to
b0df0d1
Compare
e7312b3
to
9038fcb
Compare
9038fcb
to
00006d2
Compare
Looks like it isn't quite building the
I guess we need to pack https://github.com/Humanizr/Humanizer/blob/v2.2/NuSpecs/Humanizer.Core.nuspec in particular... looks like it's normally done directly by the repo's CI with I'm not familiar with a good way to do something like |
00006d2
to
f9faf63
Compare
Thanks, I was able to put together a Now that I see that
Strangely, as you can see in the output, something in roslyn downloads Edit: maybe it's dotnet/roslyn#47290 ? |
Nice, I think that command seems reasonable. I'm not quite following what's pointing to a download happening. If it's about the nupkg in I don't really know why NuGet always does that, but it's convenient for us. We use it to do a check for this exact problem. 😄 We look for any package in the package restore cache that has the same id/version as a nupkg in the source-built blob feed. If there are any, we make sure it's byte-for-byte identical, as proof that the source-built version of the package is what ended up being used: https://github.com/dotnet/source-build/blob/master/tools-local/tasks/Microsoft.DotNet.SourceBuild.Tasks.XPlat/GetSourceBuiltNupkgCacheConflicts.cs. I'd expect that to throw a decently clear warning if you have a restore happening from the wrong feed here. |
Oh. I see. Thanks, that clears things up. The nuget packages are indeed bit-by-bit identical:
|
f9faf63
to
e83b81c
Compare
repos/humanizer.proj
Outdated
WorkingDirectory="$(ProjectDirectory)" | ||
IgnoreStandardErrorWarningFormat="true" /> | ||
|
||
<Exec Command="$(DotnetToolCommand) pack $(ProjectDirectory)src/Humanizer/Humanizer.csproj /p:NuspecFile=$(ProjectDirectory)NuSpecs/Humanizer.Core.nuspec /p:NuspecBasePath=$(ProjectDirectory)src/ /p:NuspecProperties=Version=2.2.0 /p:Configuration=$(Configuration)" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there some way to pull the Version
value from eng/Version.Details.xml
and use it here instead of hardcoding 2.2.0
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can add <HumanizerCorePackageVersion>2.2.0</HumanizerCorePackageVersion>
to eng/Versions.props
and use it from there. If Humanizer.Core ever gets updated with auto-update, this value will update as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! That would result in the version being in 2 places: eng/Versions.props
and eng/Version.Details.xml
. Is there some way to use the value from Versions.props
in Version.Details.xml
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No. That's the pattern for ProdCon. When these files are auto-updated, the version and sha get updated in Version.Details.xml and the corresponding version tag gets updated in Versions.props.
0de1500
to
2f27b3a
Compare
eng/Versions.props
Outdated
<HumanizerCorePackageVersion>2.2.0</HumanizerCorePackageVersion> | ||
<PrivateSourceBuildReferencePackagesPackageVersion>1.0.0-beta.20562.2</PrivateSourceBuildReferencePackagesPackageVersion> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Merge conflict with adjacent line.
(I think it would be reasonable to put this in a new propertygroup just to force Git to ignore this in the future. Adjacency doesn't seem to me to be a very useful heuristic for meaningful conflicts in this file. 😛)
This is https://github.com/Humanizr/Humanizer (different from https://github.com/Humanizer/Humanizer !) Humanizer shows up as a dependency of ASP.NET Core and roslyn-analyzers. This tries to fix that. Supposedly it also ships with the SDK. Fixes: dotnet#1767
2f27b3a
to
6691b42
Compare
This is https://github.com/Humanizr/Humanizer (different from https://github.com/Humanizer/Humanizer !)
Humanizer shows up as a dependency of ASP.NET Core and roslyn-analyzers. This tries to fix that. Supposedly it also ships with the SDK.
Fixes: #1767