When using NuGet 3.4 beta, an InvalidOperationException gets triggered with the message:
"The UTC time represented when the offset is applied must be between year 0 and 10,000.
Parameter name: offset"
A similar bug used to manifest on .NET proper's System.Runtime.Caching according to a Microsoft knowledge base article. I think that mono needs a similar fix. The bug is known to manifest itself only when a machine lies in a timezone with a positive offset with respect to UTC.
Hey Dylan. Thanks for your report. Can provide more instructions on how to reproduce it? Which nuget binary did you use, what system are you running on, specifically, what're the timezone settings, etc. Also a link to the mentioned MS KB article would be great.
I have used the NuGet binary from the NuGet.CommandLine package v. 126.96.36.1997. I am using the Central European Timezone i.e. GMT+1 on Linux x86. https://support.microsoft.com/en-us/kb/2346777
The same behavior during cake builds (downloading Xamarin.Component addin) on Mac with:
- mono 4.2.4 (stable channel) and 4.4.0 (alpha)
- nuget 3.4.4-rc
workaround is to use nuget 2.x (I did use 2.8.6)
I can also reproduce this using Xamarin Studio 6.1 from the alpha channel which uses NuGet 3.
Using a time zone with a positive offset (e.g. UTC+2) then Xamarin Studio will fail to install certain packages, such as XamarinComponent 188.8.131.52, with the 'The UTC time represented when the offset is applied must be between year 0 and 10,000' error. If I use UTC+0 or a time zone with a negative offset (e.g. UTC-5) then Xamarin Studio will successfully install the NuGet package. Note that Xamarin Studio needs to be restarted after the time zone change.
I have worked around this by hacking the nuget package itself. I set the URL in the xmlns declaration in the nuspec to use "2012/06" instead of "2011/08" as the month in the URL. This later month is used in nuspecs made by .NET CLI and DNX but not by the nuget command line tool. I have asked the NuGet team to fix in teh past but they seem to have ignored me.
My repro steps:
1) Switch the Mac's time zone to be Central European Summer Time (Berlin - Germany).
2) Make sure XamarinComponent is not in the local cache so it gets downloaded.
rm -rf ~/.nuget/packages/XamarinComponent/
3) Run nuget.exe (version 3.4.4 downloaded from http://dist.nuget.org/index.html). NuGet 3.4.3 has the same problem.
mono nuget.exe install XamarinComponent -version 184.108.40.206 -verbosity detailed
The XamarinComponent NuGet package is downloaded and extracted into the current directory.
NuGet fails with the following output:
Attempting to gather dependency information for package 'XamarinComponent.220.127.116.11' with respect to project '~/Projects/Tests', targeting 'Any,Version=v0.0'
Attempting to resolve dependencies for package 'XamarinComponent.18.104.22.168' with DependencyBehavior 'Lowest'
Resolving actions to install package 'XamarinComponent.22.214.171.124'
Resolved actions to install package 'XamarinComponent.126.96.36.199'
Adding package 'XamarinComponent.188.8.131.52' to folder '~/Projects/Tests'
WARNING: Install failed. Rolling back...
System.AggregateException: One or more errors occurred. ---> System.ArgumentOutOfRangeException: The UTC time represented when the offset is applied must be between year 0 and 10,000.
Parameter name: offset
at System.DateTimeOffset.ValidateDate (DateTime dateTime, TimeSpan offset) <0x1bbcc00 + 0x0013c> in <filename unknown>:0
at System.DateTimeOffset..ctor (DateTime dateTime) <0x1bb8fd0 + 0x000e6> in <filename unknown>:0
at System.DateTimeOffset.op_Implicit (DateTime dateTime) <0x1bbce30 + 0x00040> in <filename unknown>:0
at System.IO.Compression.ZipArchiveEntry.get_LastWriteTime () <0x5218960 + 0x0005f> in <filename unknown>:0
at NuGet.Packaging.PackageArchiveReader.CopyFiles (System.String destination, IEnumerable`1 packageFiles, NuGet.Packaging.Core.ExtractPackageFileDelegate extractFile, CancellationToken token) <0x52177c0 + 0x002f7> in <filename unknown>:0
at NuGet.Packaging.PackageExtractor.ExtractPackage (NuGet.Packaging.PackageReaderBase packageReader, System.IO.Stream packageStream, NuGet.Packaging.PackagePathResolver packagePathResolver, NuGet.Packaging.PackageExtractionContext packageExtractionContext, CancellationToken token) <0x5216fb0 + 0x001a1> in <filename unknown>:0
at NuGet.ProjectManagement.FolderNuGetProject.InstallPackageAsync (NuGet.Packaging.Core.PackageIdentity packageIdentity, NuGet.Protocol.Core.Types.DownloadResourceResult downloadResourceResult, INuGetProjectContext nuGetProjectContext, CancellationToken token) <0x52168f8 + 0x00297> in <filename unknown>:0
at NuGet.PackageManagement.NuGetPackageManager.ExecuteInstallAsync (NuGet.ProjectManagement.NuGetProject nuGetProject, NuGet.Packaging.Core.PackageIdentity packageIdentity, NuGet.Protocol.Core.Types.DownloadResourceResult resourceResult, System.Collections.Generic.HashSet`1 packageWithDirectoriesToBeDeleted, INuGetProjectContext nuGetProjectContext, CancellationToken token) <0x5215e28 + 0x00052> in <filename unknown>:0
at NuGet.PackageManagement.NuGetPackageManager+<ExecuteNuGetProjectActionsAsync>d__54.MoveNext () <0x51f5090 + 0x00d33> in <filename unknown>:0
Trying the same test on Windows works without any errors.
I am running this with Mono 4.4.0 (mono-4.4.0-branch-c7-baseline/5995f74 Thu Jun 2 15:13:10 EDT 2016)
This problem does not occur with all NuGet packages. It seems to happen for NuGet packages that are generated with Mono as far as I am aware.
I wonder if this other bug #40916 has fixed the underlying problem. It seems to be related since it uses DateTime.MinValue if the last write time is missing in the zip file. Using DateTime.MinValue can be a problem if the value is then casted to a DateTimeOffset value as explained in:
It seems that this has been fixed in Mono 184.108.40.2060.
I tried a build of Mono before the fix for bug #40916 was applied and a build with the fix applied.
Build before fix applied (NuGet fails):
Mono 4.5.2 (master/1d73474 Mon Jun 20 08:26:45 EDT 2016)
Build with fix for #40916 (NuGet works):
Mono 4.5.2 (master/d1d72cd Mon Jun 20 09:32:05 EDT 2016)
I ran the same the test steps outlined in comment c#6 and Mono 220.127.116.110 looks good to me.
*** This bug has been marked as a duplicate of bug 40916 ***
*** Bug 42145 has been marked as a duplicate of this bug. ***
@Matt, How did you install Mono 18.104.22.1680 ?
@hopewise - I was testing an internal build of Mono 4.5.2 which I have access to. No versions of Mono 4.5 have been published publicly as far as I am aware. The fix is on the mono/master branch on GitHub.
so, shall I install mono from master? can you please show me how to install Mono from mono/master branch on GitHub?
@hopewise - There are instructions on the mono GitHub repository on how to build mono from source:
However it may be simpler to just use a workaround with the version of Mono you have already such as use NuGet v2 instead of NuGet v3. You can also temporarily switch your local timezone as another slightly more complicated fix.
Thanks, how would I use NuGet v2 instead of v3?
NuGet v2 can be downloaded: http://dist.nuget.org/index.html
Or if you are using Mono then it ships with NuGet v2.
But that link at http://dist.nuget.org/index.html is for Visual Studio, its for Windows, where can I download v2 for Mac? thank you..
nuget.exe is a .NET console application that will work with Mono. The following link should work fine with Mono: