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

[Bert-Proesmans]

Can anyone instruct me what i need to do to make this issue go away? (I know about the powershell one liner as a workaround)

From the response i interpreted that some fix has been applied, but these specific libraries still have a faulty modification date. So far i updated Visual studio (which, i supposed, includes updated nuget binaries), looked for newer versions of the relevant libs to update and removed my local package cache. The end result didn't change, where i expected the modification date to be set correctly again.

[Pilchie]

We haven't published the new versions yet. We will as part of our next servicing update when that is ready.

[analogrelay]

This should be resolved. Please let us know if you're still seeing this issue!

[dougbu]

Reopening because Extensions portion of the targeting pack was not previous rebuilt

[dougbu]

3.1.8 is now out with this fix included