DLL Timestamps Not Consistent Between Deployments

[edleatherbury]

I’ve read several posts here about how Nuget handles timestamps for package contents, but my situation is a little different. Depending on the deployment target, I’m seeing different dll timestamps from within the same package version.

For instance, TeamCity built and created a package on 2018-09-28 21:45. This package was immediately deployed to a test server then to an integration server. The extracted dlls on the test server are dated 2018-09-28 21:46 and the dlls on the integration server are 1 minute later. This makes sense if the timestamps reflect when the package is extracted.

I deployed that same package to production today however (2018-10-03), and the timestamps do not follow this pattern. These dlls are dated 2018-09-29 01:45.

My interest was piqued so I downloaded the package from Octopus to my local machine and extracted the contents. Sure enough, the dlls are timestamped 2018-09-29 01:45. That’s exactly 4 hours after they were initially compiled on 2018-09-28.

To sum up, I’m seeing three weird things:

1. The timestamps in the nupkg don’t reflect when the dlls were actually compiled.
2. Some deployments use the extract date as a timestamp.
3. Some deployments use the (incorrect) compilation date as a timestamp.

This isn’t causing any real problems for us, it’s just a little confusing when comparing timestamps across servers. I’d love to hear an explanation as to why this is the case however.

[Shane_Gill]

Hi @edleatherbury,

Thanks for getting in touch. It sounds like you are as confused about NuGet behaviour as we are. If you are keen to delve into the extraction logic our fork of NuGet is here: https://github.com/OctopusDeploy/NuGet.Client

We have vague plans to consolidate all of the package extraction logic which we hope will remedy these NuGet quirks. Zip packages should extract with the correct timestamps if you have the flexibility to move to zips.

Cheers,
Shane