Microsoft.Extensions.ObjectPool has invalid file modified times

[peppy]

The new 3.1 release of Microsoft.Extensions.ObjectPool has incorrect modified dates for its contained (and exposed) dll files. This in turn causes package failure of any project including this package (due to NuGet/Home#7001).

[Bert-Proesmans]

I encountered exactly the same symptoms on
Microsoft.Extensions.Caching.Memory.dll
Microsoft.Extensions.Caching.Memory.xml
Microsoft.Extensions.DependencyInjection.Abstractions.dll
Microsoft.Extensions.DependencyInjection.Abstractions.xml
Microsoft.Extensions.Logging.Abstractions.dll
Microsoft.Extensions.Logging.Abstractions.xml
Microsoft.Extensions.Options.dll
Microsoft.Extensions.Options.xml
Microsoft.Extensions.Primitives.dll
Microsoft.Extensions.Primitives.xml

It also prevents me from running NuGet pack.

[rynowak]

@aspnet/build

[rynowak]

Sorry, clicked the wrong button.

[jeroenlandheer]

All Microsoft.Extensions packages are on 1-1-1980. Same problems here, it prevents us from publishing PowerShell packages.

[jeroenlandheer]

For everyone who's having trouble (probably everyone who's in a timezone above GMT), you can use this PowerShell script to change the date of the files to a value which allows you to pack with Nuget:

Get-ChildItem | Where {$_.LastWriteTime.Year -eq '1980'} | % {$_.LastWriteTime = $_.CreationTime }

[dougbu]

@rrelyea I suspect we built 3.1.0 in the window while pack determinism was true i.e. before NuGet/NuGet.Client#3060 was merged and NuGet/Home#8599 was fixed. What exactly do we need to upgrade e.g. the .NET Core SDK in order to get that fix?

[dougbu]

/fyi @johnbeisner @mmitche @aspnet/build @leecow @dagood @dleeapho @MichaelSimons @richaverma1 @nguerrera @richlander @SteveCarrollMSFT this is a 3.1.0 content issue.

[wtgodbe]

We also need to update the SDK to fix the package icon issue - if this will also be caught by that, then that's even more motivation to do so

[rrelyea]

We fixed in final 3.0.100 - so use that or later.

[mmitche]

We fixed in final 3.0.100 - so use that or later.

@rrelyea This also fixed in 3.1.100, yes?

[rrelyea]

3.0.100 matches NuGet 5.3 and VS 16.3
3.1.100 matches NuGet 5.4 and VS 16.4
Yes, we fixed on the last day or two of 3.0.100 and did not change behavior after that.
(we have not tried to refix, etc...)

@nkolev92