-
-
Notifications
You must be signed in to change notification settings - Fork 252
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
Error when running dotnet pack if my timezone is GMT >0 (e.g. Singapore or Europe) #277
Comments
Seeing this too when updating from version |
Strange. I can confirm the timestamp on the files in the .nupkg do not reflect when they were actually created. While I think ultimately NuGet shouldn't fail to pack because of this, let me see if I can provide a workaround. I'm not sure why I get those strange timestamps in files from a CI build, so this might take a little extra effort to investigate. |
Maybe a dotnet sdk 3.0 / code sign issue? |
I'm writing up a minimal repro right now and testing on Windows. Looks like it has nothing to do with code sign. |
release was build with preview9, have you tried preview8 or earlier? |
The version of NuGet in the 3.0 SDK intentionally removes timestamps when creating the .nupkg file as a part of a new NuGet feature called "deterministic packaging". Once that .nupkg is extracted on another machine, it appears it can triggering a different NuGet bug, NuGet/Home#7001, which has trouble adding files to a .nupkg which have a timestamp of 1/1/80 or older. I don't have a good way to opt-out of deterministic packaging. NuGet turns this feature on using the same MSBuild property -- @wendellestradairely I was unable to reproduce this on a clean machine using the 2.2.300 SDK. I'm in the Pacific Time Zone (GMT-7). What about you? I'm wondering if this is issue further affected by which timezone you're in? If so, we might be seeing the perfect storm of NuGet bugs (cref NuGet/Home#7395) cc @nkolev92 |
@natemcmaster My time zone is currently set in Kuala Lumpur, Singapore (UTC+08:00). I also tried removing all .net 3.0 preview SDKs and runtimes and still having the same error. I'm not getting an error with CommandLineUtils v2.3.0 though. It seems like a problem specific to v2.4.0. |
I'm on CEST time zone (UTC+2) dotnet sdk: 2.2.401 |
Haha, wow. I confirmed timezone is the problem on my own machine, too. However, it's not the timezone of the computer at the time of pack which matters, rather the timezone during restore, which puts the file in your $HOME/.nuget cache. Let me see if there is a reasonable workaround for this... |
@wendellestradairely @viceice this only appears to reproduce if running |
Then i had to upgrade all our build machines, which would be a lot of work. I'll try to update one of them and pin our ci for that job. btw seeing this issue on sdk v2.2.402 too. |
@natemcmaster It's fine with me using 2.3 of this library for now. I cant upgrade to 3.0 SDK. There are several 1st party and 3rd party libraries that I'm currently using with my main project that don't currently support 3.0. Thanks for looking into this issue by the way. I'm happy using this awesome library! |
I'm working on a fix...standby for testing and validation: #278 |
ok, installing sdk 3.0-rc fixes the problem. |
I verified a fix locally and have pushed a fix. It will take a few hours for 2.4.1 to propagate to NuGet.org. When that becomes available, please let me know if this issue persists. |
@natemcmaster Thank you so much. I'll look forward to the latest nuget package when it becomes available. |
https://www.nuget.org/packages/McMaster.Extensions.CommandLineUtils/2.4.1 Happy to help! This was a fun one 😁 |
Updated to 2.4.1. Works perfectly!! Thank you. 👍🥇💯 |
Hi @natemcmaster I tried to look into your workaround here, but it seems you moved the file and/or the workaround. I can't seem to find the audit trail linking back to the removal of the workaround. Can you please let me know? It seems like my project is running into this problem. When I diff the unzipped nupkg, the only change I see is the psmdcp file name (but the actual psmdcp files are identical). <Project>
<!-- Workaround https://github.com/NuGet/Home/issues/7001 -->
<Target Name="DisableNuGetDeterministicPackaging"
BeforeTargets="GenerateNuspec"
AfterTargets="CoreCompile" Condition="$(RazorLightNonDeterministicPackaging) == 'True'">
<Warning Text="Disabling Deterministic Packaging" />
<PropertyGroup>
<Deterministic>false</Deterministic>
</PropertyGroup>
</Target>
<Target Name="EnableNuGetDeterministicPackaging"
BeforeTargets="GenerateNuspec"
AfterTargets="CoreCompile" Condition="!($(RazorLightNonDeterministicPackaging) == 'True')">
<Warning Text="Enabling Deterministic Packaging" />
<PropertyGroup>
<Deterministic>true</Deterministic>
</PropertyGroup>
</Target>
</Project> Run via: dotnet pack --configuration Release -o .\deterministicPack /p:RazorLightNonDeterministicPackaging=False
dotnet pack --configuration Release -o .\nonDeterministicPack /p:RazorLightNonDeterministicPackaging=True |
@jzabroski I think you may be hitting a different issue. The problem I ran into happened with a prerelease SDK. The NuGet team resolved the root cause before releasing .NET Core 3. |
Got it, thanks for your help. I'm getting closer to figuring it out. |
Describe the bug
A clear and concise description of what the bug is.
I tried to reference this library to my .NET Core global tool project via
dotnet add package
but it produces "The DateTimeOffset specified cannot be converted into a Zip file timestamp." error when runningdotnet pack
.To Reproduce
Steps to reproduce the behavior:
dotnet add package McMaster.Extensions.CommandLineUtils
dotnet build
.dotnet pack
.Expected behavior
A clear and concise description of what you expected to happen.
Should be able to package the project as a nuget package.
Screenshots
If applicable, add screenshots to help explain your problem.
Additional context
Add any other context about the problem here.
The text was updated successfully, but these errors were encountered: