Feature Request: Add System.Diagnostics.FileVersionInfo.GetVersionInfo() to "allow list" as Property Function

[yuehuang010]

Steps to reproduce

Project file

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Target Name="Start">
  <Message Text="$([System.DateTime]::Now.ToString('yyyy.MM.dd'))" />
  <Message Text="$([System.Diagnostics.FileVersionInfo]::GetVersionInfo('C:\Windows\System32\notepad.exe').FileVersion)" />
</Target>
</Project>

Expected behavior

Run

Actual behavior

Build started 6/25/2018 7:20:06 PM.
Project "C:\Test\test.proj" on node 1 (default targets).
Start:
2018.06.25
C:\Test\test.proj(5,12): error MSB4212: Invalid static method invocation syntax: "[System.Diagnostics.FileVersionInfo]::GetVersionInfo('notepad.exe').FileVersion". The type "System.Dia
gnostics.FileVersionInfo" is either not available for execution in an MSBuild property function or could not be found.
Done Building Project "C:\Test\test.proj" (default targets) -- FAILED.
Build FAILED.

Justification

My SDK is built in a strange way, in which, timestamp is not a reliable way to tracked incremental build nor updates. The solution is to either create a version.txt on disk that changes every run or get the version from an adjacent .dll or .exe. System.Diagnostics.FileVersionInfo offer such feature as a direct static call. It returns a string that represents the version.

[kwstnr]

Did you have any Progress with this issue?

[rainersigwald]

This seems like a reasonable request. One workaround is to set the environment variable MSBUILDENABLEALLPROPERTYFUNCTIONS=1, which removes the allow-list check. But that's only suitable for controlled builds, not for requiring to use an SDK or NuGet package.

Related issue: it might be nice to compare these versions using #3212, but neither is necessary to implement the other.

[virzak]

Was anyone successful with MSBUILDENABLEALLPROPERTYFUNCTIONS=1? Didn't work for me at all.

[shuffle2]

I came across this while trying to find a good way to get the ProductVersion of $(VCToolsRedistDir)vc_redist.x64.exe (needed because VCToolsVersion does not match the actual version that is installed/visible in registry after installing)

MSBUILDENABLEALLPROPERTYFUNCTIONS=1 does work, but it's not really a good solution because my build environment currently doesn't do env setup before calling msbuild.exe

[KalleOlaviNiemitalo]

FileVersionInfo on Windows reads the VERSIONINFO resource, but the implementation for Unix reads managed assembly metadata instead and does not see any version information in unmanaged files like notepad.exe, or in .NET single-file executables. Using FileVersionInfo can thus make a build system less portable. I'm not sure making that easier to use is a good idea.

OTOH, if your build system already requires Windows and needs to read the Win32 version information of vc_redist.x64.exe, then FileVersionInfo is cheaper than writing your own PE and VERSIONINFO parsers. If you cannot use MSBUILDENABLEALLPROPERTYFUNCTIONS, then perhaps you can call FileVersionInfo from an inline task instead.

[shuffle2]

Yes, I've been trying to make the inline task fit into my project with no luck so far. The task itself works fine, however I'd like to use the output (the ProductVersion String) in <ItemDefinitionGroup><ClCompile><PreprocessorDefinitions>, and that seems troublesome. Even if I make the inline task get executed very early in the build, I cannot for the life of me figure out how to reference the output value in the ItemDefinitionGroup (or otherwise accomplish it, like filling the metadata from within the Target I've created to execute the Task).

[KalleOlaviNiemitalo]

If it is difficult to set PreprocessorDefinitions metadata, you could instead make the task write a #define directive to a file and then #include that where needed.