Building project with PreserveCompilationContext and PreserveCompilationReferences set to true, creates .dlls in refs folder without modifed date

[Dainius14]

Describe the bug

Building project with PreserveCompilationContext and PreserveCompilationReferences set to true, creates .dlls in refs folder without modifed date.

To Reproduce

1. Create an empty asp core project.
2. Add this code to .csproj

    <PropertyGroup>
        <PreserveCompilationReferences>true</PreserveCompilationReferences>
        <PreserveCompilationContext>true</PreserveCompilationContext>
    </PropertyGroup>

3. Build the project.
4. Go to bin/../../refs folder.
5. See .dll with no Modified date.
   

Further technical details

• ASP.NET Core version: 3.1.6

.NET Core SDK (reflecting any global.json):
 Version:   3.1.302
 Commit:    41faccf259

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.17763
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\3.1.302\

Host (useful for support):
  Version: 3.1.6
  Commit:  3acd9b0cd1

.NET Core SDKs installed:
  1.0.4 [C:\Program Files\dotnet\sdk]
  2.1.4 [C:\Program Files\dotnet\sdk]
  2.1.200 [C:\Program Files\dotnet\sdk]
  2.1.201 [C:\Program Files\dotnet\sdk]
  2.1.202 [C:\Program Files\dotnet\sdk]
  2.1.302 [C:\Program Files\dotnet\sdk]
  2.1.402 [C:\Program Files\dotnet\sdk]
  2.1.505 [C:\Program Files\dotnet\sdk]
  2.1.602 [C:\Program Files\dotnet\sdk]
  2.2.105 [C:\Program Files\dotnet\sdk]
  3.0.100 [C:\Program Files\dotnet\sdk]
  3.1.101 [C:\Program Files\dotnet\sdk]
  3.1.201 [C:\Program Files\dotnet\sdk]
  3.1.301 [C:\Program Files\dotnet\sdk]
  3.1.302 [C:\Program Files\dotnet\sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.All 2.1.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.1.4 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.1.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.1.9 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.1.17 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.2.3 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.1.4 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.1.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.1.9 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.1.17 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.2.3 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.0.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.1.1 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.1.3 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.1.6 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 1.0.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 1.1.2 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.0.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.0.7 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.0.9 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.2 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.4 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.9 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.17 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.2.3 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.1.1 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.1.3 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.1.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.1.6 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 3.0.0 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 3.1.1 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 3.1.3 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 3.1.5 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 3.1.6 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

Notes

This issue does not happen when targeting older ASP.NET Core (3.0, 2.2).
I've tried specifying multiple 3.1 SDKs and the same bug happens.
Seems to be related dotnet/extensions#2750

[mkArtakMSFT]

@JunTaoLuo where this should go?

[Pilchie]

Also tagging @dougbu, since this might have just changed with the ref assemblies changes.

[dougbu]

Doesn't relate to any recent changes in how we create ref/ assemblies since those have been limited to our 'master' branch. This instead duplicates dotnet/extensions#2750 aka NuGet/Home#8599.

The bad news is

1. We don't have tests that make sure the modification date of DLLs (ref/ or not) aren't 1980-01-01 00:00
2. When I open the microsoft.aspnetcore.app.ref v3.1.x packages, I see the modification dates are exactly that invalid value

The good new is I don't see similar issues with the 5.0 versions of Microsoft.AspNetCore.App.Ref nor any of our runtime packages.

Problems originate in broken Microsoft.Internal.Extensions.Refs.3.1.0-* packages from Microsoft.Internal.Extensions.Refs.3.1.0-preview1.19506.1 to Microsoft.Internal.Extensions.Refs.3.1.0-rtm.19565.4 We didn't rebuild that package after 3.1.0 RTM and the NuGet team fixed dotnet/extensions#2750 and NuGet/Home#8599. In other words, we may need to reopen dotnet/extensions#2750

@Pilchie should we rebuild Microsoft.Internal.Extensions.Refs and ship another targeting pack in (say) 3.1.8❔

Or, should we document the following hack❔

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

/fyi @rrelyea

[Pilchie]

Doh! I missed that this was 3.1 and not a 5.0 preview. I think we should consider fixing this by servicing the targeting pack, but first I want to understand what the customer scenario is.

@Dainius14 - can you describe the impact of this issue? What does it prevent you from doing?

[Dainius14]

Creating a package from the solution with Nuget 4.8.1 fails with the same error as in the previously mentioned isssue - The DateTimeOffset specified cannot be converted into a Zip file timestamp. We found a workaround to use older Nuget 4.5.0, which doesn't fail on that step. We tried versions up to 5.6 and it still fails.
Since we will not be jumping straight to 5.0, but will be probably waiting for a LTS, living such a long time with older Nuget is not ideal.

And we must use these two flags, because we're compiling templates at runtime (otherwise it throws missing Antiforgery.dll error).

[dougbu]

Fix for this should be in our 3.1.8 release

[Pilchie]

@dougbu this should be closed now, right?

[dougbu]

I was waiting for the 3.1.8 release but should have closed this after @wtgodbe and I confirmed the targeting packs looked good.