Why is the default option for building Windows containers inside VS2022 to compile outside of the container?

I have a requirement to containerize a .NET Framework 4.8 app that can't be upgraded to Dotnet Core. Inside Visual Studio when you use the out of the box Docker Support, it'll create a dockerfile that's just 4 lines and it does the build outside of the container build process and just feeds it in.

Essentially, the Dockerfile looks something like this and it's just feeding into docker whatever is in obj/Docker/publish.

FROM mcr.microsoft.com/dotnet/framework/aspnet:4.8-windowsservercore-ltsc2019
ARG source
WORKDIR /inetpub/wwwroot
COPY ${source:-obj/Docker/publish} .

Is there a reason that Microsoft sets this as the default? I get that it's faster to do the build - but doesn't it defeat a large reason why you want to containerise it - to standardise the build process.

That means you would have to make sure that everywhere you do the build - whether it's your own local machine or a CI CD pipeline - you have to make sure the right software is installed.

If it was a Linux Container deploying a web app, it would typically be a multistage process where you have a stage that builds and publish and then another stage that grabs the published output from the first stage with an image that just has the runtime.

FROM mcr.microsoft.com/dotnet/aspnet:8.0 AS base
USER app
WORKDIR /app
EXPOSE 8080
EXPOSE 8081

FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
ARG BUILD_CONFIGURATION=Release
WORKDIR /src
COPY ["WebApplication3/WebApplication3.csproj", "WebApplication3/"]
RUN dotnet restore "./WebApplication3/WebApplication3.csproj"
COPY . .
WORKDIR "/src/WebApplication3"
RUN dotnet build "./WebApplication3.csproj" -c $BUILD_CONFIGURATION -o /app/build

FROM build AS publish
ARG BUILD_CONFIGURATION=Release
RUN dotnet publish "./WebApplication3.csproj" -c $BUILD_CONFIGURATION -o /app/publish /p:UseAppHost=false

FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "WebApplication3.dll"]

Is there a reason why Microsoft want you to do the build outside of the container build process? Is this just a limitation of Windows Containers?

Unfortunately, we don't have a good answer to that. I asked internally at Microsoft and these are different approaches implemented by different teams. Both have pros and cons and it end up with inconsistency to users. Both Windows and Linux containers can have very simple dockerfiles that will rely on a compilation outside of the build process of the container or they can have very complex dockerfiles that compile your code/build at container build time. The usage of each will depend on your use case. I have passed this feedback of inconsistency internally, though. In any case, if you want to have the same experience as Linux containers on the Windows case, you can follow the documentation here: https://github.com/microsoft/dotnet-framework-docker/blob/main/samples/README.md