A workaround is to use a workspace image built from Fedora 41

Below is a working example -

https://github.com/cgruver/dev-spaces-dotnet/tree/main/workspace-container-image

More findings related to air-gapped environments.

Looking at this https://github.com/dotnet/vscode-csharp/blob/2f591c271ace0f4d9401ef1b0b4b41db0908fe65/package.json
There are three different binaries that this extension tries to download once it gets installed in the VSCode:

• Debugger -> https://vsdebugger.azureedge.net/coreclr-debug-2-0-5/coreclr-debug-linux-x64.zip
• OmniSharp -> https://roslynomnisharp.blob.core.windows.net/releases/1.39.10/omnisharp-linux-x64-net6.0-1.39.10.zip
• Razor -> https://download.visualstudio.microsoft.com/download/pr/0289a1d7-09a8-4aed-bf9a-e8942243fe9d/0[…]rlanguageserver-linux-x64-7.0.0-preview.23516.2.zip

So, to get it working in an air-gapped environment, the following subdomains need to be opened for external access:

.azureedge.net
.blob.core.windows.net
.visualstudio.microsoft.com

Another finding is that the C# extension used in this sample stack does not work on air-gapped environments, as it triggers an external dependency downloaded from microsoft.com [1] during its initialization at runtime.

[1]https://github.com/dotnet/vscode-csharp/blob/2f591c271ace0f4d9401ef1b0b4b41db0908fe65/package.json#L774

I was able to get the debugger working using the latest release of the free-csharp-vscode (2.45.25) working on a custom tool image (based on quay.io/fedora/fedora-minimal:42). The custom tool image is available here quay.io/redhat_na_ssa/devspaces-dotnet-8:fedora42 and the devfile to test it is here https://github.com/rafaeltuelho/devspaces-dotnet-web-api-sample/blob/main/devfile.yaml

Debugger stop working with muhammad-sammy.csharp extension version v2.45.25 in UBI9, it worked in v2.39.29

looks like new version of csharp extension requires GLIBCXX_3.4.30, I tried to run the debugger manually:

/checode/remote/extensions/muhammad-sammy.csharp-2.45.25-universal/.debugger/netcoredbg/netcoredbg --interpreter=vscode  

and got

/checode/remote/extensions/muhammad-sammy.csharp-2.45.25-universal/.debugger/netcoredbg/netcoredbg: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.30' not found (required by /checode/remote/extensions/muhammad-sammy.csharp-2.45.25-universal/.debugger/netcoredbg/netcoredbg)

[user@workspaceb4c81171ff624520-769f57cd7c-z9z4h dotnet-web-simple]$ strings /lib64/libstdc++.so.6 | grep GLIBCXX
GLIBCXX_3.4
GLIBCXX_3.4.1
GLIBCXX_3.4.2
GLIBCXX_3.4.3
GLIBCXX_3.4.4
GLIBCXX_3.4.5
GLIBCXX_3.4.6
GLIBCXX_3.4.7
GLIBCXX_3.4.8
GLIBCXX_3.4.9
GLIBCXX_3.4.10
GLIBCXX_3.4.11
GLIBCXX_3.4.12
GLIBCXX_3.4.13
GLIBCXX_3.4.14
GLIBCXX_3.4.15
GLIBCXX_3.4.16
GLIBCXX_3.4.17
GLIBCXX_3.4.18
GLIBCXX_3.4.19
GLIBCXX_3.4.20
GLIBCXX_3.4.21
GLIBCXX_3.4.22
GLIBCXX_3.4.23
GLIBCXX_3.4.24
GLIBCXX_3.4.25
GLIBCXX_3.4.26
GLIBCXX_3.4.27
GLIBCXX_3.4.28
GLIBCXX_3.4.29
GLIBCXX_DEBUG_MESSAGE_LENGTH

Since in DS 3.9 che-code editor requires node 18.x, the old content of Dockerfile that installs node 16.x won't work
We have to update workaround in the Release notes text, something like:

• Use a different image from the following sources:

• • link:https://issues.redhat.com/secure/attachment/12960372/12960372_Dockerfile[Custom UBI-9 based Dockerfile]

• • link:https://issues.redhat.com/secure/attachment/12960373/12960373_devfile.yaml[devfile.yaml]

• Starting from DS 3.9:

• • link:https://issues.redhat.com/secure/attachment/13065853/Dockerfile-1[Custom UBI-9 based Dockerfile]

• • link:https://issues.redhat.com/secure/attachment/13065852/devfile-1.yaml[devfile.yaml]

jvrbkova@redhat.com could you take a look please

rhn-support-mleonov : it's hard to read "Release Note Text:" with "-" at the middle:

I would propose to distinguish editor name itself:

For 3.6 I'd say we can use the upstream UDI (based on UBI 9) based image.

For 3.8, we can look at having a UDI image in Dev Spaces that's based on UBI/RHEL 9, which we would deliver in parallel with the other UBI 8 based images; then over time we can migrate the rest of the 13 images to UBI 9 as well.

Custom UBI-9 based Dockerfile is:
Dockerfile

Devfile is:
devfile.yaml

It could be tested with this sample (the repository provides Devfile and Dockerfile as well): https://github.com/svor/dotnet-web-simple/tree/dotnet-custom-image

For clarification: Debugging a .NET application is possible (now, with DS 3.5) using a custom image (no need to wait for Dev Spaces 3.6 or 3.7): vsvydenk please share Devfile and Dockerfile.

I am changing the title of this issue to clarify that this issue is about the UDI image not perfectly crafted for the .NET sample and that, in general, debugging a .NET application with Dev Spaces is possible using a custom image.