Generated .exe file is missing version info

[tfenster]

If I publish my 3.1 console app using the following command, then the resulting .exe file does have the version info set:
dotnet publish "client.csproj" -c Release -r win-x64 --self-contained true /property:PublishTrimmed=true /property:PublishSingleFile=true /property:Version=0.1.0.0 -o /app/publish

If I do the exact same thing in a container using the mcr.microsoft.com/dotnet/core/sdk:3.1-nanoserver-1809 image, the resulting .exe file does not have the version info set.

Steps to repro:

1. Create a sample console project using dotnet new console -o client
2. cd client
3. Run dotnet publish "client.csproj" -c Release -r win-x64 --self-contained true /property:PublishTrimmed=true /property:PublishSingleFile=true /property:Version=0.1.0.0 -o /app/publish
4. Check the properties of file c:\app\publish\client.exe. It should show something like this, as is correct in my opinion
   
5. Run docker run --rm -ti -v "<full-path>\client:c:\app" mcr.microsoft.com/dotnet/core/sdk:3.1-nanoserver-1809 (of course replace <full-path> with your path) to get a session in the container
6. cd app
7. Run dotnet publish "client.csproj" -c Release -r win-x64 --self-contained true /property:PublishTrimmed=true /property:PublishSingleFile=true /property:Version=0.1.0.0 -o /app/publish, exactly as above
8. Check the properties of file <full-path>\client\publish\. It should show something like this, in my opinion a bug
   

dotnet --version shows 3.1.100 in both cases. Am I missing something?

[swaroop-sridhar]

If you publish the app without /property:PublishTrimmed=true /property:PublishSingleFile=true does it change the behavior?

[tfenster]

The generated .dll gets the metadata inside the container as well as directly on my machine. The .exe doesn't get the metadata even without those properties inside of the container

[tfenster]

@swaroop-sridhar any feedback on this?

[swaroop-sridhar]

@tfenster The SDK transfers information (ex: resources/icons) from the App DLL to the Host EXE using the HostModel DLL. Looks like some information (VersionInfo resource) is missing in this transfer.

CC: @wli3

[swaroop-sridhar]

@wli3 This issue should probably be moved to Runtime repo (wrt HostWriter)
The HostModel simply copies resources between PE Files, not sure how the versioning info can be missed. This needs further investigation.

[wli3]

@swaroop-sridhar after Immo's permission change, no one can move issues anymore. So i will just use the old copy paste issue mover, is that ok?

[tfenster]

@wli3 @swaroop-sridhar would that be here https://github.com/dotnet/runtime/issues? I am happy to create a copy there, if that helps

[swaroop-sridhar]

@tfenster, yes that's the right repo. Let's keep the issue here for now, until we figure out how to transfer the issue. Thanks.

[bravecobra]

I seem to have the exact same issue, and it is reproducible.

[tfenster]

@bravecobra absolutely 100% and easily reproducible. Unfortunately there hasn't been any feedback apart from discussing whether or not this is the right repo and how to maybe get it somewhere else

@swaroop-sridhar @wli3 any progress on this?

[bravecobra]

I can confirm that the version information is compiled into the assembly. With reflection you get the correct version from the assembly itself, however that information isn't copied to the PE header when building on Linux/container targeting win-x64.

[swaroop-sridhar]

@tfenster @bravecobra I think I understand the problem here.

The PE resources are transferred from App.dll to the host App.exe only when building on Windows -- because the resource handling code currently uses native Win32 API. So, when the app is published from Linux or nanoserver, the resources are not transfered.

There is an issue dotnet/runtime#3828 filed for implementing ResourceUpdater in managed code. Once this happens, the version information will be transfered regardless of the host machine configuration.

@wli3 I think we can resolve this issue as a dup of dotnet/runtime#3828.
Isn't it?