Mono not producing native binaries with version header in Windows

[safern]

While working on collapsing the mono official builds into single legs, I noticed that we don't produce a runtime pack for Windows:

runtime/eng/pipelines/runtime-official.yml

Lines 227 to 249 in 704be18

	- template: /eng/pipelines/installer/installer-matrix.yml
	parameters:
	jobParameters:
	liveRuntimeBuildConfig: release
	liveLibrariesBuildConfig: Release
	isOfficialBuild: ${{ variables.isOfficialBuild }}
	useOfficialAllConfigurations: false
	buildFullPlatformManifest: false
	runtimeFlavor: mono
	platforms:
	- OSX_x64
	- Linux_x64
	- tvOS_x64
	- tvOS_arm64
	- iOS_arm
	- iOS_arm64
	- iOS_x64
	- iOS_x86
	- Android_arm
	- Android_arm64
	- Android_x64
	- Android_x86
	- Browser_wasm

I added that to my test change and the windows build failed with:

F:\workspace\_work\1\s\.packages\microsoft.dotnet.build.tasks.sharedframework.sdk\5.0.0-beta.20280.1\targets\framework.dependency.targets(201,5): Missing FileVersion in 1 shared framework files:
F:\workspace\_work\1\s\artifacts\bin\mono\Windows_NT.x64.Release\coreclr.dll [F:\workspace\_work\1\s\src\installer\pkg\projects\netcoreapp\src\netcoreapp.depproj]

As a workaround I will be setting PermitDllAndExeFilesLackingFileVersion=true for mono on windows in installer/netcoreapp.depproj to start producing the runtime pack for Windows. However, we should fix this.

cc: @steveisok @akoeplinger @marek-safar

[Dotnet-GitSync-Bot]

I couldn't figure out the best area label to add to this issue. Please help me learn by adding exactly one area label.

Tagging subscribers to this area: @directhex
Notify danmosemsft if you want to be subscribed.

[safern]

@akoeplinger as discussed offline, assigning to you.

[safern]

When fixing this we should remove the temporary workaround in: https://github.com/dotnet/runtime/pull/37511/files#diff-9fac0b3c275ca346bd7e392f9ae3807cR7

[hoyosjs]

Another issue here that might not be obvious is that the symbol indexer will see CoreCLR and try to index the special modules with it: the DAC (mscordaccore/libmscordaccore) and the DBI (mscordbi/libmscordbi). I don't expect this to be an issue because it indexes modules with a index composed of the version + an identifier composed of timestamp and size on windows and the build ID on linux, but I don't know if the same indexing logic applies to Mono. See other impact in #34202. @mikem8361, what happens if the indexer doesn't find the dac and dbi in the same package as coreclr.

[mikem8361]

If there is no DAC or DBI module for the coreclr module (currently only “coreclr.dll”, “libcoreclr.so” or “libcoreclr.dylib”), the uploader ignores it and displays an warning if the tracing level is high enough.