Bad developer experience in dotnet

[ac10n]

I'm writing this after being frustrated for not being able to develop dotnet on my Linux machine. Please note that I'm an experienced dotnet developer (about 18 years) and a moderately experienced Linux user (a few years + doing DevOps). Also, bold fonts are to ease skimming, not a textual equivalent of shouting. I do develop with several other stacks and constantly promote dotnet by telling developers how many of their problems have a cleaner solution in the dotnet ecosystem.

I use vscode for all my development. The c# extension relies on mono and, as a result, depends on some files that are not installed by following the official SDK installation guideline. On my Fedora 34, there is apparently no way to install them at all. I have already spent hours searching to understand what should I do, with no success.

OmniSharp.MSBuild.ProjectLoader
        The "Microsoft.AspNetCore.Razor.Tasks.DiscoverDefaultScopedCssItems" task could not be loaded from the assembly /usr/lib64/dotnet/sdk/5.0.204/Sdks/Microsoft.NET.Sdk.Razor/build/netstandard2.0/../../tasks/net46/Microsoft.NET.Sdk.Razor.Tasks.dll. Invalid Image Confirm that the <UsingTask> declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask.

I started paying for JetBrains Rider, but it requires a whole different mentality than the minimalist one I get with vscode. I also prefer to continue using only one IDE for all development (to avoid confusing hotkeys, etc)

Because of this error, my project is not loaded by Omnisharp. So code completion and everything is broken.

I'm maintaining on a few dotnet projects. I'm having trouble with all of them.
I'm also working on another project that uses a different stack. I believe developer productivity could be improved multiple times if it used dotnet stack. As an R&D, I dedicated about 30 hours to try to implement the functionality in dotnet. As of now, all that time is spent trying to fix my setup.

Please put this in perspective: dotnet + c# + asp.net core + entityframework is in my opinion the best stack to write complex data manipulation backend for a wide range of use cases. Unfortunately, tooling in Linux is hampering this down.

Please consider this decision-making: If I want to start a serious project in dotnet, I want developer engagement to be frictionless for anyone using a major operating system: Windows/Mac/Linux(Debian, Ubuntu, Fedora and a few others). This is the only viable way in a distributed project (for instance, in open-source).

People need a simple guideline like this:

1. Install dotnet SDK (link to the official docs)
2. Clone this project
3. On vscode, the project can make suggestions for which extensions they need

But now because of the undocumented dependency of the c# extension, they get errors in their first steps. I know you prefer to worry about Windows and Visual Studio users, but this is damaging to the ecosystem.

I believe this can be fixed in one of these ways:

1. Make the c# extension (or a new clone of it) depend only on the dotnet SDK (preferred)
2. Consider its dependency an official requirement of having a working dotnet SDK and include guidelines in SDK installation docs for all platforms.

Please don't leave developers in the dark. Please don't close this issue as being related to OmniSharp. That project can decide to only support specific use-cases. This is a developer productivity issue.

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[dagood]

It sounds like you ran into dotnet/vscode-csharp#4360, which will reportedly have a fix included in the next version of the .NET 5 SDK that will be built by Fedora. Have you taken a look at that issue to see if your situation matches?

As far as I know, this scenario is meant to work, so this is a valid bug report, and I don't quite understand the concern.

More broadly, if you have suggestions to add to the docs for a situation like this (even if temporary), I believe they'd be happy to receive a PR (edit pencil at the top right).

[ac10n]

Hello Davis
Thank you for your message. I had stumbled upon the thread you linked and unfortunately, that did not work for me.

About the concern: I'm worried that the problem is being addressed at a symptom level, not at the root cause.

My conclusion with my limited observations is that we are dealing with a system that has an implicit dependency between its different parts (omnisharp and SKD). This is a recipe for problems that arise in different times, forms and are difficult to diagnose and even to explain.

I try to summarize (from my memory) the observations that suggest we are dealing with such a problem:

1. dotnet build is working properly, but omnisharp fails
2. Omnisharp depends on mono. This by itself can cause enough confusion: should we install mono on the dev machine? Is it packaged with omnisharp? What is even omnisharp? I just installed the c# extension in vscode.
3. Quoting bitflame from the thread you linked: "Do you find that every time you update Fedora the problem resurfaces". The problem is first reported in January, so it has been affecting people for more than half a year. I have not been able to use the c# extension ever since I migrated to Fedora, which is about a year ago.
4. Why I'm missing a file from net46? From my understanding, on Linux we only have core 1x, core 2x, core 3x and dotnet5.0. What even is that?
5. Why do maintainers of dotnet SDK on different platforms make a similar mistake? Are we going to expect the same cycle of problems when each Linux distribution starts including dotnet in its repositories?

I'm sure you have good answers to all these questions. But I have a simple answer for all of them: omnisharp depends on something that is not visible to most people as a component of dotnet SDK (including people who maintain dotnet repositories on Linux distributions). So that component keeps breaking.

I don't know why omnisharp depends on mono, probably there is a historical reason for that, but this is hurting an unknown number of people.

If I'm wrong, please just close this thread and I'll continue dealing with my development in Jetbrains Rider long enough for Fedora repos to become usable.

[dagood]

/cc @dleeapho @omajid

[dleeapho]

@dseefeld, @crummel it sounds like the feedback and technical appreciation @AlirezaHaghshenas has provided coincides with your efforts to make Omnisharp to work in a lasting way with distro-native .NET (Fedora, RHEL).

[omajid]

For the specific issue reported here - OmniSharp not working with the source-built SDK - we (or rather, @crummel) fixed it back in July with dotnet/source-build#2178.

That said, it looks like this problem is going to appear again in source-built .NET 6: dotnet/source-build#2478