New bundled mono causes grief on macOS, required to install global mono-mdk

[NinoFloris]

New bundled mono causes grief on macOS, required to install global mono-mdk
This is on 1.21.11, latest vscode, targetting netcoreapp3.1.

Installing mono-mdk (tested with 6.6.0 and 6.8.0) solves all issues.

This seems to happen with assembly loading of projects that are not csproj (fsproj for instance ;).

[JoeRobich]

@NinoFloris Can you provide additional details such as the OmniSharp log and descriptions if the issues you are seeing?

[NinoFloris]

It may be related to my previous issue from 3 years ago
#1623

[NinoFloris]

Actually it's astounding how poorly all this is still working 3 years later. That mono is still involved at all tells a story on its own too. Ionide, which is a purely community run project, doesn't have a hard dep on mono for years now.

If I wasn't such a big believer of hanlon's razor I'd say omnisharp was co-opted from the community, and once controlled by Microsoft brought up to something barely passable and kept there to drive VS sales. You're definitely succeeding to drive sales, though Rider isn't VS.

I know all this is bordering vitriol, and it's not meant as anything personal, but it has to be said, omnisharp is hurting the perceived value of C# for newcomers starting through vscode. All JS and python devs don't use any other editor, and they are plenty. Most people's initial reaction to poorly working tech won't be to step up and buy Rider or VS, but to stop trying C# all together.

[cartermp]

This is unfortunately a consequence of the attempt to bring up a usable experience during .NET Core 1.x, and that legacy carrying over. IMO the right thing to do is simply drop support for .NET Framework/Mono and move over to .NET SDK-only workspace and project system. Until that happens I doubt any issues of this sort will reasonably get better.

[NinoFloris]

Thanks @cartermp, understood, it's surely unfortunate that this prevents a decent onboarding experience, there are no warnings or obvious diagnostics to figure this one out. I was obviously frustrated by all this still standing in the way of a good experience in my previous comment. As a matter of fact it really did damage the motivation some people had to continue looking at the ecosystem.

The general point stands either way, "that legacy carrying over" I presume has fairly little to do with * wanting * this to carry over, the underlying is issue is almost as old as .net core.

Say that a decision is voiced by the maintainers in favor of getting rid of mono I would be willing to help, but right now I'm not sure what direction anybody wants to take anything here.

[cartermp]

Right now we're not taking any concrete steps aside from triaging the large number of issues to see:

• What is stale and what is not
• Which "area" each issue falls under (setup/install, project system, debugging, etc.)

Separately we've been doing some more detailed research into what kinds of people use .NET and vscode as their daily driver, and where things work vs. where they fall apart. The triage is an input into that. The overall goal is to make it a much better experience, especially when VS Online moves from preview to GA. How that happens isn't being determined right now, but I'm personally going to advocate for exclusively .NET SDK-style project support, mostly because supporting other project types would be an enormous complexity increase that is far too expensive to handle.

[guidobouman]

The past years we've needed to install external Mono versions to fix issues with the packaged mono builds. Can this extension not install and update the correct mono version that is required?

Even multiple years later the same kind of bug keeps popping up: The shipped mono version is out of date, a new version of dotnet core is not supported. This first happened with dotnet core 2, now again with 3.1.

See:
#3290 (comment)
#3806 (comment)

[JoeRobich]

Closing as mono is no longer bundled with O#.