Windows explorer does not display assembly attributes after a dotnet build on an F# dll

[livarcocc]

From @ivaylo5ev on September 25, 2018 19:5

Steps to reproduce

1. Create an F# library project using the new project style and multi-targeting the following .net versions:

• net45
• net46
• netstandard1.6
• netstandard2.0

2. Build the project using Visual Studio (2017 Community in my case).

   2.1. After the build completes, navigate to the output directory (say bin/Debug) and examine the file properties of the output dll. When I right-click the output dll for any framework version in Windows Explorer, and select Properties, then Details tab, I can see the values of the assembly-level attributes that I have specified in my project, and they are correct.

3. Use the .net sdk to build the same project by calling

   dotnet build MyProject.fsproj

   3.1 As in step 2.1 navigate to the output directory and examine the build output files. The propertes shown by Windows Explorer on the dll files are blank, unlike the result from the Visual Studio (MSBuild) output.

Expected behavior

The assembly-level attributes should be visible in the properties window.

Actual behavior

The assembly-level related fields are blank.

Additional observations

• the issue is possibly related to an F# build sdk problem, although the following observations lead in a different direction
• file sizes of dotnet build results are slightly smaller
• when I reference the library project in another a test project and open the properties tab in Visual Studio for my dll in the references section, the relevant attribute values are displayed correctly, regardless if I used dotnet build or Visual Studio's MSBuild.
• when examining my build output (both from MSBuild and dotnet build), the file containing the assembly level attributes is listed for compilation).

The above observations lead me to think (this is just a guess) that the reason for Windows Explorer not showing the attribute info is because the dotnet build output does not have an application manifest embedded, while MSBuild generates one.

Is there a way to make dotnet build produce dlls that have the assembly-level data visible in Windows Explorer?

Environment data

dotnet --info output:

.NET Core SDK (reflecting any global.json):
 Version:   2.1.400
 Commit:    8642e60a0f

Runtime Environment:
 OS Name:     Windows
 OS Version:  6.3.9600
 OS Platform: Windows
 RID:         win81-x64
 Base Path:   C:\Program Files\dotnet\sdk\2.1.400\

Host (useful for support):
  Version: 2.1.2
  Commit:  811c3ce6c0

.NET Core SDKs installed:
  1.0.2 [C:\Program Files\dotnet\sdk]
  1.0.3 [C:\Program Files\dotnet\sdk]
  1.0.4 [C:\Program Files\dotnet\sdk]
  1.1.0 [C:\Program Files\dotnet\sdk]
  2.1.4 [C:\Program Files\dotnet\sdk]
  2.1.202 [C:\Program Files\dotnet\sdk]
  2.1.400 [C:\Program Files\dotnet\sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.All 2.1.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 1.0.4 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 1.0.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 1.1.1 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 1.1.2 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.0.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.0.9 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.2 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]

To install additional .NET Core runtimes or SDKs:
  https://aka.ms/dotnet-download

Copied from original issue: dotnet/cli#10047

[livarcocc]

@nguerrera @peterhuene is this done by the compiler? @KevinRansom any chance this is not being passed down to the compiler?

[livarcocc]

From @nguerrera on September 27, 2018 3:32

Yes, the compiler would be responsible for creating the appropriate win32 resources here.

[livarcocc]

@KevinRansom @nguerrera can we confirm we are passing the parameters to the compiler? If we are, we should move this issue to fsharp.

[cartermp]

This one was resolved in .NET Core 3