Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TimeDateStamp of IMAGE_FILE_HEADER in PE Header is not right? #8600

Closed
yyjdelete opened this issue Aug 10, 2017 · 2 comments
Closed

TimeDateStamp of IMAGE_FILE_HEADER in PE Header is not right? #8600

yyjdelete opened this issue Aug 10, 2017 · 2 comments

Comments

@yyjdelete
Copy link

Maybe this is not the right repo to report it, but I'm not sure where is the right repo to report it.

Steps to reproduce

  1. dotnet new
  2. dotnet build

Expected behavior

TimeDateStamp(can be found at offset 0x88 in most case) should be the same as buildTime, as it used to be in netframework and other .exe files.

Actual behavior

TimeDateStamp seem to be some random number, like "0x8FF50636 (2046/7/14 16:49:58)", "0xA9161448 (2059/11/23 7:01:28)"

Environment data

dotnet --info output:

.NET Command Line Tools (2.0.0-preview2-006497)

Product Information:
 Version:            2.0.0-preview2-006497
 Commit SHA-1 hash:  06a2093335

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.16257
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\2.0.0-preview2-006497\

Microsoft .NET Core Shared Framework Host

  Version  : 2.0.0-preview2-25407-01
  Build    : 40c565230930ead58a50719c0ec799df77bddee9

And switch to 1.1.0 by global.json, and get the same result.

.NET Command Line Tools (1.1.0)

Product Information:
 Version:            1.1.0
 Commit SHA-1 hash:  d6f4336106

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

Microsoft .NET Core Shared Framework Host

  Version  : 2.0.0-preview2-25407-01
  Build    : 40c565230930ead58a50719c0ec799df77bddee9

Change TargetFramework to net461 didn't resolve this, but the traditional csproj with

<TargetFrameworkVersion>v4.6.1</TargetFrameworkVersion>
<LangVersion>latest</LangVersion>

works well in the same PC(build with VS15.3.0P7.0 to use the latest rosyln as netcore be), so I'm not sure if it's an issue with rosyln.

@yyjdelete
Copy link
Author

Already found the reason at dotnet/cli#1297, #1


Just mark. Add the below to your csproj if you need the timestamp, and the value of TimeDateStamp in Deterministic mode is always (value & 0x80000000) != 0

  <PropertyGroup>
    <Deterministic>false</Deterministic>
  </PropertyGroup>

@dzmitry-lahoda
Copy link

dzmitry-lahoda commented May 17, 2019

First search result on the web for me. So

    use self = Assembly.GetExecutingAssembly().Location |> File.OpenRead |> PEReader
    let timeDateStamp = self.PEHeaders.CoffHeader.TimeDateStamp |> int64 |> DateTimeOffset.FromUnixTimeSeconds     
    printfn "I was built at %s" (timeDateStamp.ToString("yyyy-MM-ddTHH:mm:ssZ"))

to convert it into normal date.

@msftgits msftgits transferred this issue from dotnet/cli Jan 31, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants