Salta al contenuto principale


We are using Microsoft Visual Studio Code on MacOS. There is a file "launch.json" which controls the behavior of a little clicky green triangle. The top of launch.json says "version": "0.2.0".

This documentation file:

code.visualstudio.com/docs/csh…

Claims when "type" is "dotnet", you may use a "cwd" key to specify the CWD of the run executable. However, for us, this does not work. Visual Studio displays an error on that part of the JSON, and running it, the "cwd" directory seems to be ignored.

Why?

in reply to anne.💫

@ann3nova Although that would not be legal JSON in this context, it appears that it gives the same results with and without a comma (apparently it is not validating JSON)
in reply to mcc

One thing I hate about IDEs is to some extent they're like "hey, we've invented a thing that's like programming, except the documentation is really vague" mastodon.social/@whitequark/11…


upsettingly, there's no static schema you can consult stackoverflow.com/a/73366400

in reply to mcc

*rubbing eyes* What local testing seems to indicate is that although the documentation claims (in my read) that the accepted JSON keys with type "dotnet" is a superset of type "coreclr", in fact they're just… different… and despite that page claiming "cwd" is available in launch.json, this is only true for coreclr not dotnet projects. What is the difference between a coreclr and a dotnet project? The documentation does not seem to hint.
in reply to mcc

I'm desperate enough I'd actually just start digging into the VS Code source code at this point but afaict the interpretation is determined by a nest of plugins so I'm not actually sure what source code to read. It seems unthinkable that when using Microsoft's IDE to debug an application with Microsoft's programming language, you can't control the PWD at debug time
in reply to Felix S K II (pnkfelix)

@pnkfelix It reproduces on Windows. I do not have access to a Linux machine with vscode installed currently.
in reply to mcc

CoreCLR is .NET Core (the successor to .NET Framework, but before modern .NET), dotnet is what you want if you're targeting .NET 5 or later.
in reply to Graham Sutherland / Polynomial

@gsuberland Can you clarify— do you mean this is the meaning of the words "coreclr" and "dotnet", or do you specifically mean that this is the meaning of the "type" key in a Visual Studio Code launch.json stanza?
in reply to mcc

kinda both.

CoreCLR is the .NET Core Common Language Runtime, which is the runtime used for applications that target .NET Core (the thing we got after .NET Framework when they were retooling the whole language and runtime)

dotnet is the umbrella term given to .NET 5 onwards, so the "dotnet runtime" would be the CLR for .NET 5 and onwards (yes I know this is horrible naming).

in this case "coreclr" and "dotnet" in that file are referring to .NET Core and .NET 5+ project types respectively

in reply to Graham Sutherland / Polynomial

so if you're explicitly targeting the (older) .NET Core stuff, then you want "coreclr". if you're targeting modern .NET (5+) then you want "dotnet".

they use slightly different project formats hence the disparity in how the launch config works. it'd be nice if VS Code didn't make this such a mess but sadly it's a big headache.

in reply to Graham Sutherland / Polynomial

@gsuberland Wait what? .NET Core and .NET 5+ don't use different project formats though? It's both still SDK-style .csproj, no?

Also I don't think your description of CoreCLR vs .NET is quite accurate: CoreCLR is the name of the actual runtime itself that ".NET" uses, but it's not the only one: some platforms still use the Mono runtime (which yes, Microsoft still develops themselves too). CoreCLR is kind of an "implementation detail" term so it's weird that VSCode ever used it.

in reply to mcc

@gsuberland

> they use slightly different project formats hence the disparity in how the launch config works.

Did I misread this? That says the project formats are different and *that's* why the launch config is different.

in reply to mcc

@PJB sorry I'm getting pulled in 8 different directions here and it's gotten a bit mentally overwhelming to answer everyone

I'll come back to this later if you haven't gotten it fixed

@PJB
in reply to Graham Sutherland / Polynomial

@gsuberland @PJB
- It isn't fixed
- I have however worked around it by ignoring PWD entirely and constructing paths relative to the EXE, which seems to be technically adequate for current use
- My github bug appears to have passed the triage stage so perhaps that is the best place for me to receive support

thanks

in reply to Graham Sutherland / Polynomial

if you're targeting modern .NET, I believe what you want is the workingDirectory property on one of the launch profiles in launchSettings.json
in reply to Graham Sutherland / Polynomial

@gsuberland github.com/microsoft/vscode/is…
in reply to Jason Bowen 🇺🇦

@jbowen @gsuberland This is thankfully a regular old heuristics-based bot (providing a check which potentially could save maintainer time but it turns out is not relevant in this situation) so at least I didn't boil the ocean by asking a question.