dotnet-docker VS dotnet-framework-docker

This cool method lets you whip up optimized apps that get along swimmingly with Docker. Neat, huh? --platform values. Take a peek at this sample to see the pattern in action!

You can also use the .NET Docker images to run (or build from source and then run) .NET applications.

Sadly, lots of dotnet apps still out there. Luckily, there's a container for that too!

A search of "alpine 3.17 ssl" brings up this link that shows the same error.

Actually, it looks like I am a bit out of the loop, and there is an official .NET runtime for Linux, so you can use it like any other Linux docker images. Looks like there are examples here: https://github.com/dotnet/dotnet-docker

It is good that you are thinking about security 😊. there is an issue in dotnet repo here https://github.com/dotnet/dotnet-docker/issues/1772 that have hardened examples.

You can use .NET without using ASP.NET Core (yes, the names are confusing right now, they dropped the "Core" suffix for the platform but did not drop the suffix for the web framework). Microsoft publishes a Docker image for .NET for when you just want to run some compiled CIL, but they also provide a Docker image where it includes .NET and ASP.NET Core for when you run a compiled ASP.NET Core web app. (https://hub.docker.com/_/microsoft-dotnet/)

Keeping the whole Maritime theme alive with Docker (and Kubernetes), I jumped into the sea of Docker Hub with millions of containers and found out that Microsoft hosts all the .NET related container images as .NET by Microsoft registry.

ARG OPENCV_SHARP_BUILD_TAG=2 ARG SDK_VERSION=6.0.202-bullseye-slim-amd64 ARG RUNTIME_VERSION=6.0.4-bullseye-slim FROM syamaner/opencvsharp-build:$OPENCV_SHARP_BUILD_TAG AS opencv # Given we are building a .Net application, the build does not have to be in the target architecture. # Reference: https://github.com/dotnet/dotnet-docker/issues/1537#issuecomment-755351628 FROM mcr.microsoft.com/dotnet/sdk:$SDK_VERSION as build ARG TARGETPLATFORM WORKDIR /src COPY . . # Select the correct RID for the target architecture. # run dotnet publish as usual and pass the RID. RUN if [ "$TARGETPLATFORM" = "linux/amd64" ]; then \ RID=linux-x64 ; \ elif [ "$TARGETPLATFORM" = "linux/arm64" ]; then \ RID=linux-arm64 ; \ elif [ "$TARGETPLATFORM" = "linux/arm/v7" ]; then \ RID=linux-arm ; \ fi && \ dotnet publish -c release -o /app -r $RID --self-contained false # Copy the application as well as native dependencies to the final stage and build the final image without any unnecessary files. FROM mcr.microsoft.com/dotnet/runtime:$RUNTIME_VERSION as final WORKDIR /app # Copy opencv sharp native binding and runtime dependencies. COPY --from=opencv /artifacts/ /usr/lib/ RUN ldconfig COPY --from=build /app/ /app/ ENTRYPOINT [ "dotnet", "/app/OpenCVSharpBenchmarkApp.dll" ]

The official Microsoft .Net Framework images are here.

https://hub.docker.com/_/microsoft-dotnet-framework

It was about 2.7 / 2.8 GB in size.

I would say you should be moving to .Net 6 it's been several years now that .Net Core has been out so there is no excuse.

None of this is an excuse to get a 10Gbps internet connection to your house. I have a 500Mbps connection and with the corporate firewall my laptop gets 100-200Mbps connection and pulling those containers was like 10 minutes.

servercore:ltsc2019 is not required, because Windows images are already based on an OS image. So downloading mcr.microsoft.com/dotnet/framework/aspnet:4.8-windowsservercore-ltsc2019 would already pull ltsc2019. I think I also see the issue you might be having. I think runtime4.8 does not enable the WebServer component, which makes sense, because it'd be a security risk to open useless, unconfigured IIS ports if you're not running an actual web app in there.