4

We are attempting to build a .NET core 3.1 app within a container, using dotnet publish, dotnet build or dotnet msbuild commands, with different parameters. Which succeeds, but the problem is that EXE output never shows any file Details (Copyright, File version, etc. are empty), while DLLs do contain specified information. We've tried several different containers, as well as researching online and trying different command parameters, for versioning (there are a few). Also, running identical dotnet publish command on my Windows 10 machine directly, works as expected, no issues.

I've also attempted separating dotnet build and dotnet publish (--no-build) commands and copying a code signed EXE in-between, in case there is a trust issue, but nothing worked.

Dockerfile content (also used dotnet publish instead of msbuild):

FROM mcr.microsoft.com/dotnet/core/sdk:3.1-alpine3.11

ARG Version="5.6.7"

WORKDIR /build

COPY ./src $WORKDIR

RUN dotnet restore

RUN echo $Version

RUN dotnet msbuild abc.csproj /t:Build /p:PublishSingleFile=True /p:SelfContained=True /p:PublishProtocol=FileSystem /p:Configuration=Release /p:Platform=x64 /p:TargetFrameworks=netcoreapp3.1 /p:PublishDir=publish /p:RuntimeIdentifier=win-x64 /p:PublishReadyToRun=False /p:PublishTrimmed=False /p:VersionNumber=$Version /p:VersionPrefix=$Version /p:Version=$Version /p:AssemblyVersion=$Version /p:AssemblyVersionAttribute=$Version /p:FileVersion=$Version /p:AssemblyFileVersionAttribute=$Version

Steps to reproduce:

  1. Create Dockerfile, similar to above
  2. Run docker build command for a .NET Core console application (replace abc.csproj)
  3. Run docker run command using container ID
  4. Copy publish contents to local file system and review EXE file Details
x00
  • 13,643
  • 3
  • 16
  • 40
DevOpsVR
  • 43
  • 6
  • For the fun of it, can you try this `dotnet publish project.sln -r win-x64 -c Release /p:AssemblyVersion=1.2.3.4` where you use `publish`, but with the `SLN` file, specify the platform, in this case `win-x64` – Andy Aug 27 '20 at 20:42
  • Building with SLN file instead of the project directly produced same results unfortunately. But it was a good step to rule out. – DevOpsVR Aug 28 '20 at 16:01
  • Dang! I really though it'd do it. That's how I build all my stuff in our CI/CD pipeline and it works for us. Good luck – Andy Aug 28 '20 at 16:03
  • It works in a container for you? Because if I run this command in Windows VM, EXE file details show up correctly, just not in any container. Thanks. – DevOpsVR Aug 28 '20 at 16:24
  • No, we aren't building in containers. They are built in the pipeline (build server) then deployed out to where they need to go. I thought maybe there was something wrong with the CLI command you were using so I wanted to see if you used exactly what I was using if it would work and go from there. Sorry to get your hopes up! – Andy Aug 28 '20 at 16:37
  • All good, understood. Thanks anyway. – DevOpsVR Aug 28 '20 at 17:21

3 Answers3

1

I think there is an issue which is still open, I think you should see what is the differnet in the SDK versions between your Container and Windows and try to use that working version in your container

LinPy
  • 16,987
  • 4
  • 43
  • 57
  • So far I've assumed that Docker hub registry provides up to date (LTS/Current) containers, with latest .Net Core SDK: https://hub.docker.com/_/microsoft-dotnet-core-sdk/ but I may need to revisit/update the minor version. Will try, thanks. – DevOpsVR Aug 28 '20 at 16:08
  • .NET minor version on my workstation (where publishing EXE shows Details correctly) is identical to what's installed on the container, 3.1.401, so that's ruled out. – DevOpsVR Aug 28 '20 at 17:18
1

This issue is described here: https://github.com/dotnet/sdk/issues/4127. From that link:

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.

That issue was closed, pointing to planned cross-platform work to re-write the way these resources are written (https://github.com/dotnet/runtime/issues/3828). That work has been pushed off to the dotnet 6.0.0 milestone, so unfortunately for now the only way to get the .exe to include these assembly info resources is to run the dotnet publish command directly on a Windows host.

Dan Wolfe
  • 548
  • 2
  • 5
0

In this thread I found a solution for myself which also solves the problem discussed here: https://stackoverflow.com/a/67336316/8041403

TL;DR

  • the nanoserver image is the problem (which is the base of the standard .NET core images)
  • use mcr.microsoft.com/dotnet/sdk:5.0-windowsservercore-ltsc2019 as image, which uses servercore
Ulfhetnar
  • 681
  • 9
  • 11