Dotnet-docker: Unable to load DLL 'gdiplus.dll' when using Windows based docker images

[tburnett80]

Steps to reproduce the issue

1. Try to use System.Drawing.Common with microsoft/dotnet:2.2-aspnetcore-runtime-nanoserver-sac2016

Expected behavior

dll loaded and System.DllNotFoundException not thrown when using System.Drawing.Common

Actual behavior

System.DllNotFoundException thown: "Unable to load DLL 'gdiplus.dll': The specified module could not be found."

Additional information (e.g. issue happens only occasionally)

System.Drawing.Common unusable with dotnet core 2.1 / 2.2 runtime images.

Output of docker version

Client: Docker Engine - Enterprise
 Version:           18.09.4
 API version:       1.39
 Go version:        go1.10.8
 Git commit:        c3516c43ef
 Built:             03/27/2019 18:22:15
 OS/Arch:           windows/amd64
 Experimental:      false

Server: Docker Engine - Enterprise
 Engine:
  Version:          18.09.4
  API version:      1.39 (minimum version 1.24)
  Go version:       go1.10.8
  Git commit:       c3516c43ef
  Built:            03/27/2019 18:20:29
  OS/Arch:          windows/amd64
  Experimental:     false

Output of docker info

Containers: 3
 Running: 3
 Paused: 0
 Stopped: 0
Images: 20
Server Version: 18.09.4
Storage Driver: windowsfilter
 Windows:
Logging Driver: json-file
Plugins:
 Volume: local
 Network: ics l2bridge l2tunnel nat null overlay transparent
 Log: awslogs etwlogs fluentd gelf json-file local logentries splunk syslog
Swarm: inactive
Default Isolation: process
Kernel Version: 10.0 14393 (14393.2906.amd64fre.rs1_release_inmarket.190401-1809)
Operating System: Windows Server 2016 Standard Version 1607 (OS Build 14393.2906)
OSType: windows
Architecture: x86_64
CPUs: 2
Total Memory: 16GiB
Docker Root Dir: D:\Docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false

[MichaelSimons]

This is a duplicate of https://github.com/dotnet/dotnet-docker/issues/618

[ericjpeters]

How is this (windows-based container) issue a duplicate of #618, which is discussing linux-based containers? When using mcr.microsoft.com/dotnet/core/aspnet:2.2-nanoserver-1809, apt-get is not available.

I am getting this exact error on a windows-based container.

What am I missing here?
Thanks!

[tburnett80]

How is this (windows-based container) issue a duplicate of #618, which is discussing linux-based containers? When using mcr.microsoft.com/dotnet/core/aspnet:2.2-nanoserver-1809, apt-get is not available.

I am getting this exact error on a windows-based container.

What am I missing here?
Thanks!

I have just switched to a custom build base image using server core as a base to handle GDI+ issues. Its easier than arguing with people who don't read or understand APT isn't the package manager on nano server.

Its unfortunate that I now have 11+ GB images vs 1-2 GB but it functions.

[MichaelSimons]

That was my mistake for resolving incorrectly. I indeed missed that the repro steps were utilizing a windows based image.

Please don't hesitate to respond or reopen issues when you spot something that is incorrect.

[Heurazio]

Same problem. Is there already a solution somewhere?

[ericjpeters]

@Heurazio There are some people saying that you can build your own container based on ServerCore, but I was not able to get that working in a way which was acceptable to me. If you find a good solution, please share!

[tburnett80]

Here is a base / run-time image I am deploying my dotnet core apps on that need GDI+ and its working for me its just the size that is not ideal. You can easily swap out the server version and framework versions.

I still compile with a build container in the smaller nano / dotnet core image I just drop the resulting assemblies into the /app dir of this image.

I haven't tried it with 2019 and 2.2+ just yet.

FROM  mcr.microsoft.com/windows/servercore:ltsc2016
SHELL ["powershell", "-Command", "$ErrorActionPreference = 'Stop'; $ProgressPreference = 'SilentlyContinue';"]

WORKDIR /app
RUN iex ((New-Object System.Net.WebClient).DownloadString('https://chocolatey.org/install.ps1')); \
    choco install dotnetcore-runtime --version 2.1.10 -y; \
    choco install aspnetcore-runtimepackagestore --version 2.1.10 -y

ENV ASPNETCORE_URLS http://*:80
EXPOSE 80

[MichaelSimons]

NanoServer isn't going to support this scenario so you are forced to use a Server Core based image. @tburnett80 suggestion of building with the nanoserver SDK image is a good one and then dropping the binaries into a server core image will work. If a self contained app will work for you, it may be an appealing option in a scenario like this.

Closing as this is a limitation of Nano Server.

[ericjpeters]

Thank you @tburnett80 ... That was extremely helpful. I would not have thought of chocolatey -- great suggestion!

[llyons]

So are we saying the base image FROM mcr.microsoft.com/dotnet/core/aspnet:2.2-nanoserver-1809 does not contain System.Drawing.Common and the file gdiplus.dll?

So the option for those containers is to use a more robust ServerCore image add in the dotnet core runtime and aspnet core runtime and end up with a larger resulting container?

did I say that correctly?

Are there any other alternatives?

[tburnett80]

You can use a Linux distro its easier and produces a smaller image. My problem is the place I work now wants to keep everything windows so until that restriction is lifted I am stuck with server core.

[llyons]

I have that same issue. Everything is windows. We just converted over to windows 2019 and that took a bit of effort. Now for a simple library we are looking at having to redo our approach..

Is there a way to add in the binaries to the nanoserver image on another layer?

[tburnett80]

Not that I know of, its an issue with the WindowsAPI being leaner than the full servercore images.
The Nano version just doesn't have the underlying infrastructure from what I have found.

[Heurazio]

@ericjpeters : Re-install Docker for Windows solved the problem for me.

[llyons]

Was able to redo the image but the size of the container with servercore is now 4.8 gb instead of 409 mb. Fairly substantial cost to include system.drawing.common (gdiplus).

I have to find a better alternative than this. stuck using windows containers.

i wonder if I can just copy the gdiplus.dll and related files to the nanoserver image

[turric4n]

I have same problem, no GDIPlus on nanoserver image and I don't want to use Linux containers because System.Drawing implementation is a mess. So have to stuck with ServerCore image.

[TheFairey]

@llyons I'm assuming copying in the dll isn't a workable solution as @tburnett80 points out the underlying infrastructure also isn't there in the OS?

[djarvis]

I am seeing this problem using mcr.microsoft.com/dotnet/core/aspnet:2.2.2 as the base image. I am assuming this is a server core image and not a nanoserver image.

[mthalman]

I am seeing this problem using mcr.microsoft.com/dotnet/core/aspnet:2.2.2 as the base image. I am assuming this is a server core image and not a nanoserver image.

@djarvis - No, all .NET Core images for Windows are Nano Server.

[djarvis]

@mthalman Ok, thanks!

So are we saying that we can't cheat and copy in some DLLs to make this work? Have we boiled this down to any particular (small?) packages that can be installed?