dotnet pack creates odd dates in package using version 3.0.100-preview9-014004

[phillipsj]

dotnet pack creates odd dates in package using version 3.0.100-preview9-014004

After switching to the version listed above our nuget packages started having very strange dates. The first date that is being displayed is inside of the nuget packages before being unpacked. The date is 12/29/1899.

Once we unpack the package, the date changes to 12/29/1979.

This only started occuring after we upgrade from 3.0.100-preview7-012821 to 3.0.100-preview9-014004.

[Macromullet]

I have confirmed this issue persists in RC1

[livarcocc]

@rrelyea

[Macromullet]

This seems to be related to deterministic packages introduced in preview 9:

https://docs.microsoft.com/en-us/nuget/release-notes/nuget-5.3
NuGet/Home#6229

Commit:
NuGet/NuGet.Client@4590967

[Macromullet]

Just confirmed using
dotnet pack -p:Deterministic=false
serves as a workaround, but it's odd that the default is to enable deterministic builds.

[DamianEdwards]

I reproduced the behavior locally on one of my existing projects too.

[nkolev92]

The deterministic property is set in the project itself.

The compiler respects the <Deterministic>true</Deterministic> property, and starting with 3.0 so does NuGet at pack time.

https://docs.microsoft.com/en-us/nuget/reference/msbuild-targets#deterministic

1980 was chosen as the min zip supported date.

The reason behind that if the customer wants deterministic binaries at build time, having deterministic packages is important too.

As @Macromullet linked NuGet/Home#6229 contains the reasoning.
Spec at https://github.com/NuGet/Client.Engineering/blob/master/Specs/Deterministic-Pack.md

[phillipsj]

@nkolev92 we don't have that property set at all in our project. Why would it default to being enabled?

[nkolev92]

It's set by default in the SDK.

https://github.com/dotnet/sdk/blame/release/3.0.1xx/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Sdk.props#L34

[phillipsj]

So it is set to true by default? That is a huge change IMO to make it default to true. Since it defaults to an older date we have packages that are not getting updated on deployment of our web app because of how deployment tools like web deploy uses the dates.

[nkolev92]

@phillipsj

How are you deploying? What's the tooling used for deployment purposes?

//cc @tmat

[Macromullet]

I echo Jamie's sentiments. The change is sensible, but breaking, and I'm not sure customers have been made fully aware of how this changes deployments in Azure. I did find that prop, and did notice that it was set to true by default, which is why I commented on it. Windows and many other deployment systems use modified time as a way to know what should be overwritten. If you don't know what's newer (if it's an alpha or beta binary and you're using semantic versioning, then then major.minor.build may not increase).

[phillipsj]

@nkolev92 we are packing with Azure DevOps using the SDK.

[rrelyea]

@Macromullet @phillipsj - @nkolev92 is asking about the "tooling used for deployment purposes" so we can understand more details when @phillipsj said:

Since it defaults to an older date we have packages that are not getting updated on deployment of our web app because of how deployment tools like web deploy uses the dates.

What are repro steps that show that this is a significant problem?

[DamianEdwards]

@phillipsj where does it go after that? I can see how this will effect deployments where assets are moved through a pipeline as a NuGet package, and then expanded out in another step and treated as loose files again, because their dates will now be fixed.

[DamianEdwards]

Hypothetical example of a build pipeline that will be broken by this:

1. Build a csproj into a nupkg and mark the nupkg as the stage output
2. Take the previous stage output and put it on a feed
3. Download the latest version of the package from the feed
4. Expand the package and then run a copy to a different target output (e.g. folder) based on file timestamps so you only copy what's newer

In this situation, you'll never get the new copies of the files as they went through a format that doesn't ever update the timestamps of the contents.