Is it meant to be possible to debug .NET projects running under .NET Aspire in Docker containers?

[zejji]

When working with .NET projects not running under .NET Aspire, it is easy to debug .NET code running inside a Docker container using Visual Studio's fast build feature as described here: https://learn.microsoft.com/en-us/visualstudio/containers/edit-and-refresh

I am working on a new distributed application running under .NET Aspire and would like:

• each of the .NET projects to run within their own Docker containers; and
• to be able to set breakpoints in any of the .NET projects and debug my code in Visual Studio.

The reason I need to use Docker containers for my .NET development are:

• I would like to use Python.NET in my .NET services, so would like to install a Python distribution into my .NET Docker containers; and
• I would like to use Yarp to reverse proxy traffic to other Docker services which are not managed by my Aspire app host, so need the various containers to be on the same Docker network.

However, it is not clear to me from the documentation whether this is intended to be possible and, if so, how. The documentation is currently ambiguous and it would be great if it could be updated if this is indeed possible.

If this is not possible, is the intention that anyone wishing to run .NET projects inside Docker containers use Docker Compose and the standalone Aspire dashboard instead?

[davidfowl]

Aspire doesn't run projects in a container today. When we do add this feature, we'll integrate with the IDE for debugging.

[zejji]

Thanks for the quick response - looking forward to that when it arrives!

[runxc1]

Here it is 18 months later and this is still the most desired missing feature. The only projects I don't use Aspire with are ones where we have a custom Docker file that installs dependencies needed for the micro service

[adamint]

There should be movement on container debug support within the next few aspire versions.

[DNVTOBS]

Was looking to see if anyone else wanted this. Good to know I'm not alone haha.

[michaeljunkin]

Would love to have that feature, we have some projects that have to run in Linux, would love to be able to debug while using Aspire.

[ashortland-eqix]

What's the answer for this? I've been playing with it and I can run the project in docker using AddDockerfile, but I cannot figure out how to get the debugger attached.

I've set the stage to base.

Added bind mounts for
/app
/src
/remote_debugger
/.nuget/packages
/.nuget/fallbackpackages
/VSTools
/HotReloadAgent.

Added labels for
com.microsoft.created-by
com.microsoft.visual-studio.project-name
com.microsoft.visualstudio.debuggee.arguments
com.microsoft.visualstudio.debuggee.killprogram
com.microsoft.visualstudio.debuggee.program
com.microsoft.visualstudio.debuggee.workingdirectory

Set tty to true

Added environment variables for
DOTNET_USE_POLLING_FILE_WATCHER
ASPNETCORE_LOGGING__CONSOLE__DISABLECOLORS
NUGET_FALLBACK_PACKAGES

Best I can tell this should be everything, but when I set a breakpoint in the project and I have AppHost selected as the startup project I get an alert on my breakpoint that a copy of the file was found in AppHost.dll but it is different so the breakpoint won't be hit.

Any tips on where to go with this would be greatly appreciated, I'm aware this is not a supported scenario at this time, but I have some unique requirements where having this work would be extremely helpful.

[NCarlsonMSFT]

@ashortland-eqix the labels you see are part of the configuration story for the .dcproj (docs). Adding them to an arbitrary container won't get you debugging.

Note this is all spit balling and mainly left as an exercise for the reader:
I don't know enough about extensibility on the aspire side, but if you're watching docker events you may already be able to get the information you need to create a more scripted approach to attach to your aspire containers (i know it's not as good as F5, but it's better than manually attaching each time).

The steps for creating an attach to container configuration file are here and the steps for invoking it are here. Assuming you are able to identify your containers and the process Ids you're running in them you should be able to generate a config file per process, and invoke the command for each of those command automation docs

[NCarlsonMSFT]

@ashortland-eqix, @ArnoldIsHereToday You've inspired me and I was able to get a POC working locally. Sadly, I can't just publish it as an example b/c i grabbed some existing parts i had lying around that i don't know the licensing of :/ Here are the parts that i know i can give away:

A) Utilities to get a cross-process COM object for automating the VS with your project:

private static EnvDTE.DTE GetDte(string projectName)
{
    var procs = GetVSProcessIds();

    foreach (var pid in procs)
    {
        var dte = GetDte(pid);
        if (dte.Solution == null || dte.Solution.Projects == null || dte.Solution.Projects.Count <= 0)
        {
            continue;
        }

        if (dte.Solution.Projects.Cast<EnvDTE.Project>().Any(p => p.Name == projectName))
        {
            return dte;
        }
    }

    return null;
}

private static int[] GetVSProcessIds()
{
    List<int> processIds = new List<int>();
    foreach (var process in System.Diagnostics.Process.GetProcessesByName("devenv"))
    {
        processIds.Add(process.Id);
    }
    return processIds.ToArray();
}

private static EnvDTE.DTE GetDte(int pid)
{
    IntPtr numFetched = IntPtr.Zero;
    IRunningObjectTable runningObjectTable;
    IEnumMoniker monikerEnumerator;
    IMoniker[] monikers = new IMoniker[1];

    //get Running object table, make a pinvoke call
    NativeMethods.GetRunningObjectTable(0, out runningObjectTable);

    //get an enumerator for entries
    runningObjectTable.EnumRunning(out monikerEnumerator);
    monikerEnumerator.Reset();

    string runningObjectNameExpected = "!VisualStudio.DTE.17.0:" + pid;

    while (monikerEnumerator.Next(1, monikers, numFetched) == 0)
    {
        IBindCtx ctx;
        NativeMethods.CreateBindCtx(0, out ctx);

        string runningObjectName;
        monikers[0].GetDisplayName(ctx, null, out runningObjectName);

        if (runningObjectName.Equals(runningObjectNameExpected, StringComparison.OrdinalIgnoreCase))
        {
            object runningObjectVal;
            runningObjectTable.GetObject(monikers[0], out runningObjectVal);
            return (EnvDTE.DTE)runningObjectVal;
        }
    }

    return null;
}

B) Find the running container:

private static string GetContainerId(string imageName)
{
    ProcessStartInfo processStartInfo = new ProcessStartInfo
    {
        FileName = "docker",
        Arguments = $"ps -q --filter \"ancestor={imageName}\"",
        RedirectStandardOutput = true,
        UseShellExecute = false,
        CreateNoWindow = true
    };

    while (true)
    {
        Process docker = Process.Start(processStartInfo);
        docker.WaitForExit();
        string[] outputLines = docker.StandardOutput.ReadToEnd()?.Split(new[] { Environment.NewLine }, StringSplitOptions.RemoveEmptyEntries) ?? Array.Empty<string>();

        if (docker.ExitCode != 0 || outputLines.Length == 0)
        {
            System.Threading.Thread.Sleep(1000);
            continue;
        }

        return outputLines.First().Trim();
    }
}

C) Invoke debugging in the container:

string containerId = GetContainerId(imageName);
using (new MessageFilter())
{
    var dte = GetDte(projectName);

    string config = Path.Combine(Path.GetTempPath(), Guid.NewGuid().ToString("N") + ".json");

    // See https://github.com/Microsoft/MIEngine/wiki/Offroad-Debugging-of-.NET-Core-on-Linux---OSX-from-Visual-Studio#attaching
    File.WriteAllText(config, $$"""
         {
          "version": "0.2.0",
          "adapter": "docker.exe",
          "adapterArgs": "exec -i {{containerId}} /remote_debugger/vsdbg --interpreter=vscode",
          "configurations": [
            {
              "name": ".NET Core Docker Attach",
              "type": "coreclr",
              "request": "attach",
              // Just assuming the target process is the entry point and has pid 1
              "processId": 1
            }
          ]
        }
        """);

    dte.ExecuteCommand("DebugAdapterHost.Launch", $"/LaunchJson:\"{config}\" /EngineGuid:541B8A8A-6081-4506-9F0A-1CE771DEBC04");

}

To make this work I added a .NET 4.7 console app to my solution (and annotated it with STAThreadAttribute for COM) and made that an additional start-up project. When debugging started my bonus console app would wait for the container using my known base image and then find the correct VS and manually invoke the attach command for the container. The biggest exercise I've left to the reader is implementing the IMessageFilter that makes cross process COM more reliable, but a quick bing search found several other people with examples for that,

Also note that this assumes vsdbg is available in the container at /remote_debugger/vsdbg, i did it as a volume mount but you could also have a special stage for debugging that adds it to the image.

[ashortland-eqix]

This is amazing! Thank you, I'll definitely be digging deeper into this!

[NCarlsonMSFT]

@ashortland-eqix, @ArnoldIsHereToday if you're still interested, I was a bit stuck on this, and having spent far too much time on it over the weekend, I now do have a sample repo you can look at: https://github.com/NCarlsonMSFT/ContainerDebuggingInAspire

The repo is taking the basic Aspire start app, throwing everything into an SDK container, and then adding auto-attaching and HTTPS.

It has some rough edges but should give you an idea of what is possible.

[CZEMacLeod]

@NCarlsonMSFT I just did almost the same thing for debugging IIS Express projects using MSBuild.SDK.SystemWeb. I put together some stuff to generically attach the VS debugger to resources automatically and have it working with IIS Express, and node available at C3D.Extensions.Aspire.IISExpress.
I haven't published this as packages yet (need to renew a signing certificate) - but will do so at some point soon.