Assembly informational attributes not applied for .net core app

[weshaggard]

@karelz commented on Fri Apr 27 2018

From @Priya91 on April 27, 2018 1:33

Repro:

1. Create a .net core app
2. Set the following properties in the csproj

<PropertyGroup>
    <OutputType>Exe</OutputType>
    <RuntimeIdentifier>win7-x86</RuntimeIdentifier>
    <TargetFramework>netcoreapp2.0</TargetFramework>
    <AssemblyTitle>Assembly Information Repro</AssemblyTitle>
    <AssemblyProduct>Assembly Information Repro</AssemblyProduct>
    <AssemblyDescription>Assembly Information Repro</AssemblyDescription>
    <Product>Assembly Information Repro</Product>
    <PublisherName>tester</Publishername>
</PropertyGroup>

3. Publish the app.

Expected:
The properties on <assemblyname>.exe are set as per the info provided in the csproj.

Actual:
The properties are set only for <assemblyname>.dll, not on the <assemblyname>.exe. Note, the .exe is the one that runs, and is shown in task manager, firewall prompts, etc. So without the process information, on task manager, it doesn't have a description, and on firewall prompts, it shows the publisher as unknown.

AssemblyMetadata.dll

AssemblyMetadata.exe

Copied from original issue: dotnet/corefx#29362

---

@karelz commented on Fri Apr 27 2018

From @kasper3 on April 27, 2018 6:21

Belongs to https://github.com/dotnet/sdk?

[livarcocc]

This is a known bug.

[tannergooding]

I have a prototype, which uses P/Invoke to get this working on Windows: https://github.com/tannergooding/sdk/tree/embed-verinfo

I am still investigating if we can use something like S.R.Metadata so that cross-platform publishing works as well (publishing for Windows, on Linux, should also embed this information).

https://github.com/dotnet/corefx/issues/7875 tracks official S.R.Metadata support for doing this.

[KalleOlaviNiemitalo]

I am still investigating if we can use something like S.R.Metadata so that cross-platform publishing works as well (publishing for Windows, on Linux, should also embed this information).

That part may be a duplicate of dotnet/runtime#3828, which has since been fixed.

Is there anything remaining in this issue, or has everything been fixed now?

[ckuetbach]

I was able to create an executable for windows running a linux docker image with these information. It seems to be fixed with this PR: dotnet/runtime#89303

It should be working since RC1 of dotnet 8.0, I did test it with RC2 and it worked.