Show Windows Container logs in the Container Tools "Logs" tab

[kamranayub]

Related: #284, #25

As a Windows Container user, I expect to see logs within the Container Tools window for my containers.

According to the docs:

Visual Studio automatically redirects stdout and stderr to the Output window when you run without debugging with Windows containers, so Windows containers started from Visual Studio using Ctrl+F5 will not display logs in this tab; use the Output window instead.

This threw me for a loop, wondering where my logs were (expectation: Logs tab, duh) as I am using Windows Containers.

As mentioned in #25, when you have a lot of containers (like two web apps and a background jobs console app), the Output window gets real messy.

If anyone has some good workarounds to at least see the logs separately (using docker exec or something), I'm all ears 👂

[NCarlsonMSFT]

@kamranayub which version of .NET are you using?

[kamranayub]

@kamranayub which version of .NET are you using?

.NET Framework 4.7.2, C# Console Project

Dockerfile created using Add Orchestrator Support:

#Depending on the operating system of the host machines(s) that will build or run the containers, the image specified in the FROM statement may need to be changed.
#For more information, please see https://aka.ms/containercompat

FROM mcr.microsoft.com/dotnet/framework/runtime:4.8-windowsservercore-ltsc2022
ARG source
WORKDIR /app
COPY ${source:-obj/Docker/publish} .
ENTRYPOINT ["C:\\app\\Jobs.Host.exe"]

[dbreshears]

This is a known limitation of .Net Framework debugging with containers. The full Framework Remote debugger is not capable of writing to stdout and we use as the entry point when debugging. This would take a bit of rearchitecture in this area, but can keep this on the backlog see if there is enough interest to prioritize at some point in the future.

[kamranayub]

This is a known limitation of .Net Framework debugging with containers. The full Framework Remote debugger is not capable of writing to stdout and we use as the entry point when debugging. This would take a bit of rearchitecture in this area, but can keep this on the backlog see if there is enough interest to prioritize at some point in the future.

Thanks, I figured it was, so I thought I'd open an issue to let others vote as well.