BuildTools version about source-build HOT 6 CLOSED

The usual approach of strings <path-to-so-dll-or-exe> | grep @ on a BuildTools dll doesnt get me a commit id either.

from source-build.

Hi guys, I think this might have been fixed with our recent build and BuildTools updates - I downloaded version 2.0.0-servicing-02104-04 from BuildToolsVersion.txt and checked the file properties for the hash, which gave me dotnet/buildtools@21e3698. I'll close this for now, please reopen or let me know if you're still seeing this issue.

from source-build.

Stupid question. How does one do that on Linux? It seems exiftool can do it for some, but not all .dll files I throw at it.

Example:

$ exiftool -FileVersion  /usr/lib64/dotnet/sdk/2.0.0/Sdks/Microsoft.NET.Sdk/tools/netcoreapp1.0/Newtonsoft.Json.dll
File Version                    : 9.0.1.19813
$ exiftool -FileVersion /usr/lib64/dotnet/sdk/2.0.0/Newtonsoft.Json.dll
Error: File format error - /usr/lib64/dotnet/sdk/2.0.0/Newtonsoft.Json.dll

from source-build.

Interesting, that particular file doesn't show properties on Windows either.
Bad file: ./x64/Release/smoke/sdk/15.5.1-preview-006908/Newtonsoft.Json.dll: PE32+ executable (DLL) (console) Unknown processor type 0xfd1d Mono/.Net assembly, for MS Windows
Good file: ./x64/Release/smoke/sdk/15.5.1-preview-006908/Sdks/Microsoft.NET.Sdk.Publish/tools/net46/Newtonsoft.Json.dll: PE32 executable (DLL) (console) Intel 80386 Mono/.Net assembly, for MS Windows

I'm looking into this.

from source-build.

I think the difference is, one is a managed assembly the other is ngened.

from source-build.

That makes sense, that won't apply to BuildTools then as all of that code is managed.

from source-build.