I'm building a C# middleware service that has to call into a 32-bit COM DLL and call a SOAP web service. The service is being written against .NET7.0 and I'm using Visual Studio 2022 Community Edition.
Because of that DLL, the project has to target an x86 Windows platform.
I would like to containerize this service. I have the latest Docker desktop installed and have added Docker support to the project.
When I hit Debug, VS correctly creates the container and downloads the expected images, but then, once the container is up and running, it just silently exits debug mode and there is no output either to the debug window or to the container tools log.
The Dockerfile is pretty much the default generated by VS:
FROM mcr.microsoft.com/dotnet/runtime:7.0 AS base
WORKDIR /app
FROM mcr.microsoft.com/dotnet/sdk:7.0 AS build
WORKDIR /src
COPY ["Trayport/Trayport.csproj", "Trayport/"]
RUN dotnet restore "Trayport/Trayport.csproj"
COPY . .
WORKDIR "/src/Trayport"
RUN dotnet build "Trayport.csproj" -c Release -o /app/build
FROM build AS publish
RUN dotnet publish "Trayport.csproj" -c Release -o /app/publish /p:UseAppHost=false
FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "Trayport.dll"]
Here's the csproj:
<Project Sdk="Microsoft.NET.Sdk.Worker">
<PropertyGroup>
<TargetFramework>net7.0-windows</TargetFramework>
<Nullable>enable</Nullable>
<ImplicitUsings>enable</ImplicitUsings>
<UserSecretsId>dotnet-Trayport-69c0cd6b-2a27-4fa8-ab42-df4d743d63e3</UserSecretsId>
<DockerDefaultTargetOS>Windows</DockerDefaultTargetOS>
<ServerGarbageCollection>true</ServerGarbageCollection>
<Platforms>x86</Platforms>
</PropertyGroup>
<ItemGroup>
<COMReference Include="GV8APILib">
<VersionMinor>0</VersionMinor>
<VersionMajor>1</VersionMajor>
<Guid>0a67e301-3ecb-47be-bba9-dc67ff219358</Guid>
<Lcid>0</Lcid>
<WrapperTool>tlbimp</WrapperTool>
<Isolated>false</Isolated>
<EmbedInteropTypes>True</EmbedInteropTypes>
</COMReference>
</ItemGroup>
<ItemGroup>
<PackageReference Include="Microsoft.Extensions.Configuration.Json" Version="7.0.0" />
<PackageReference Include="Microsoft.Extensions.Hosting" Version="7.0.1" />
<PackageReference Include="Microsoft.VisualStudio.Azure.Containers.Tools.Targets" Version="1.19.5" />
<PackageReference Include="System.ServiceModel.Duplex" Version="4.10.*" />
<PackageReference Include="System.ServiceModel.Federation" Version="4.10.*" />
<PackageReference Include="System.ServiceModel.Http" Version="4.10.*" />
<PackageReference Include="System.ServiceModel.NetTcp" Version="4.10.*" />
<PackageReference Include="System.ServiceModel.Security" Version="4.10.*" />
</ItemGroup>
<ItemGroup>
<None Update="Gv8Api.dll">
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
</None>
<None Update="trayport-api-schema.xsd">
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
</None>
</ItemGroup>
</Project>
From what I've been able to gather after copious googling, this seems to be somehow related to the fact that the VS docker build deploys and runs a 64-bit remote debugger to the container, but then attempts to attach to a 32-bit debugger. When it doesn't find one, it just stops with no output.
Then again, the problem may lie elsewhere entirely...
If it's relevant, Docker Desktop and VS are running in the same host machine, which is a 64-bit Windows 11 PC.
Based on your Dockerfile I believe you have two issues:
A quick fix for the first issue is to copy the x86 runtime into the existing image. Here is an example of changing a Dockerfile to do that.
You can fix the 2nd issue by manually specifying the debugger using ContainerVsDbgPath
, and the program to start using DockerDebuggeeProgram
. Here are the docs for those properties, and an example of setting them to support x86 debugging in a container. When making the example I needed to use ServerCore as my base image to get the x86 runtime to run, so I was able to use the full remote debugger.