BitmapDecoder fails due missing WindowsCodecsExt.dll

[bormm]

We have a .Net Framework Application that uses the regular System.Windows.Media.Imaging.BitmapDecoder class to access image files.

This currently fails within the docker container with "System.DllNotFoundException
: 'Unable to load DLL 'WindowsCodecsExt.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E)'" if access a PNG file (but not every PNG file).
I have searched for days now, but I have not found any official solution nor any official reference to WindowsCodecsExt.dll within the MSDN.

If image decoding is not fully working out of the box, how can the missing dll and whatever be added to the container? I also played with the "Server Core App Compatibility Feature" but this also seems broken in the docker container.

I attached a full runnable solution and project showing the exception that occurs at calling the BitmapDecoder.Frames property.
WindowsCodecsExtSample.zip

There are a lot of dependencies, reasons , ... why we use this class currently. For example to access multi frame images, so "use an other class to open the image" is not the solution here.

[mthalman]

@bormm - Please direct this issue to the Windows Containers forum at https://social.msdn.microsoft.com/forums/en-us/home?forum=windowscontainers. Your Dockerfile makes use of mcr.microsoft.com/dotnet/framework/runtime:4.7.2-windowsservercore-ltsc2019. There's nothing special about that image from a .NET standpoint. It's essentially just a thin wrapper around the mcr.microsoft.com/windows/servercore:ltsc2019 image which already comes with 4.7.2 installed. One thing you may want to try is using one of the main Windows image at https://hub.docker.com/_/microsoft-windows.

[bormm]

I've tested the mcr.microsoft.com/windows:1809 and yes, this worked and it also contains WindowsCodecsExt.dll.
But that image is 6GB larger!

I use dotnet-framework-docker images because

1. they are recommended for regular .net framework by MS (https://docs.microsoft.com/en-us/dotnet/standard/microservices-architecture/net-core-net-framework-containers/net-container-os-targets).

2. the dotnet aspnet image, which is based on the regular dotnet image, is are recommended by the Azure Team (https://azure.microsoft.com/en-us/blog/windows-server-2019-support-now-available-for-windows-containers-on-azure-app-service/). This recommendation is not only a nice hint, its essential because otherwise the image is not guaranteed to be in the azure image cache. If its not cached, azure containers are nearly unusable.

Conclusion:
Even complying these recommendations the .net framework support of the image is limited that even a PNG can't be loaded. Even the limitation is founded in the servercore, this is not in the hand of the image users nor me.
I can't switch the base image, I only could add the missing dll myself my own image, based on dotnet-framework. I am not sure if I am allowed to do so.

In my opinion it would much more meaningful if the Microsoft dotnet-framework-docker team would work together with the Microsoft servercore image team to provide full .net framework support in the image.

[mthalman]

I understand your frustration with not having full access to the .NET Framework API with the Server Core image. At this point in time, it'll be necessary for you to copy the required DLLs into the image. I've communicated your issue to some folks on the Windows Containers team and here is their guidance:

A user would need to do a container build on a machine where the DLL is present, copy the DLL into the image at equivalent filesystem location (via a “COPY/ADD” in their dockerfile), and then register the .DLL using regsvr. This process is less-than-ideal from a servicing perspective because if the container build is executed on a system that does not match the container image, you end up copying in a host binary whose version might be disjointed from the container version. So if a user does go down this path, the recommendation would be to make sure they’re building on a host that exactly matches the container version.