Announcement: A roadmap update on the VS Code C# extension #5276
Comments
|
Embrace, extend and extinguish. I feel like Microsoft has noticed the amount of installs the C# extension has and has to step (aka embrace) in. Especially with:
I feel like VSCode was always about (almost) open-source (fully if you use VSCodium) so this feels like a step in the bad direction. Currently the extensions has 16M installs. Will all these installs automatically switch to the closed-source part of the extension in step 2?
I would rather see a new extension in the Visual Studio Marketplace, but I get that Microsoft owns the rights to the C# extension (since it's under the publisher Microsoft) which makes it hard. I really hope that this was not a power move made by Microsoft and the OmniSharp team had a say in this. Because Microsoft already has shown that it'll make decisions to ensure that Visual Studio is more attractive (aka removing
Not only does LSP servers talk to each-other, but LSP is also implemented by other editors, like Vim (https://github.com/OmniSharp/omnisharp-vim) or Emacs (https://github.com/OmniSharp/omnisharp-emacs). I assume that Microsoft won't make extensions for these editors (since only We'll see how much love the open-source LSP server will get but I don't have much hope. This year, JoeRobich and 50Wliu have made the most commits and are both working at Microsoft. Luckily we still have Rider, so we have at least one IDE/Editor for C# that is not owned by Microsoft. |
|
While "C# in VS Code" getting some love is very much welcome, the new LSP implementation not being open source is a weird decision. I hope Microsoft reconsiders it. If it's about IntelliCode, then they can make the LSP server extensible and open source, with some optional closed source components like IntelliCode. GitHub Copilot lives as a separate extension and works everywhere, maybe a similar method can be used for IntelliCode in VS Code too? Anyway, because of Copilot I don't think IntelliCode is that important in VS Code |
|
I echo the sentiment that this being officially close sourced is a turn off. It is great that C# for VS Code gets more love, but this was also a weird omission in the past. Glad to see it starting to get corrected, but can't help to feel another mistake is being made. IntelliCode can be a separate extension like copilot, open source what you can. |
|
It's sad and short-sighted when Microsoft tries to jockey for power in the short-run (or reap rewards on existing market share) by making user-hostile decisions. This seems like another instance of embrace/extend/extinguish. It's predictable by now, but I'm not happy about it! |
|
If Microsoft could extinguish as aggressively as possible that would be fantastic, the harder they push the easier it is for me to lock down on my end and make the argument of updating to the latest .NET standard a non-issue. I assume a bunch of weirdos working as MS interns or first-years are looking at this. Read my every word: Keep doing this. The harder you break the ecosystem, the easier it is for me to maintain my software. All I have to do is say that FNA's .NET spec is not touched by Microsoft; thanks to you it's a feature and not a bug. Do not listen to anybody in this thread, commit to your wild ideas and never back down, it makes my job easier. Thanks in advance. |
|
Can you provide reasoning on why this new tools host will be closed source? This seems contradictory to the spirit of VS Code. MS has gained a ton of goodwill from developers by building open source, it would be a shame for this to change and old habits come back in to play. |
|
Closed tools all get sunset eventually, then we'll have to port all our code. I've worked at places where my whole job was porting from some closed source language that's no longer supported. Better to do it on your own schedule than be forced to unexpectedly. At least with omnisharp there was a plan b, it wasn't great but it existed. I don't know how pushing us to use their competitors products serves Microsoft. I canceled my VS subscription while it still was a choice instead of being left out to dry. |
|
Can Microsoft share the rationale behind making the aforementioned “LSP Tools Host” closed source? I think that the lack of justification makes the whole issue more open to misinterpretation. This kind of rug pull with open source projects isn’t welcome at all. I hope you fix this before it turns into another PR crisis. |
|
This kind of behavior makes me embarrassed to have an open source project relying 100% on .NET. You have extremely good technology here Microsoft, stop wasting it with these backwards business decisions. |
|
This sounds like some middle manager decision that the higher ups will reverse when they realize how absolutely asinine it is, and how much it will hurt MS goodwill. |
|
Seriously considering just downgrading all my tools to .NET Framework 4.7 at this rate, at least Microsoft can't pull the rug out from under me if I just use VS2015 forever. |
|
Microsoft should end the production race between VS Code and Visual Studio for good. |
No it sounds like a strategic move by an out of touch higher up who doesn't understand the catastrophic risk that they're putting msft in by doing this. |
|
This is not a good look. I imagine (hope) this will be changed after community outrage. I thought Microsoft said they were going to stop these random, stupid decisions from taking place? |
To this comment I can say were involved in the discussions for a good while, so this did not blind side us in any way. At the end of the day I think everyone wants a better experience for C# in vscode, and as a small indy team with not a ton of resources it is really not easy. I will say I have my concerns, and I've let those involved know my concerns (those which are being echo'd here for sure).
Things like the LSP handlers and such will live in Roslyn. Roslyn is open source, so perhaps more of the movement is to work and make the Roslyn handlers better, which then helps anyone consuming those APIs. Another thing to keep in mind, OmniSharp isn't going anywhere, and moving to an LSP model in vscode (something I've been striving to get to for a few years) will help us enable richer features in vscode and other editors. |
|
To the closed source nature of the new "host", fundamentally I know the team working on it wants to open source it, or at the very least parts of it. While I can't say for certain if that will end up being the case (hint: I don't work at Microsoft) we (Filip, me and Martin) did stress highly that Open Source is key. And that without that there would be some "special" feedback. I know Microsoft has a great track record and a terrible track record. The good:
The bad:
What I'm trying to say is it might feel like doom and gloom, but I'm hoping with the push of the greater .NET community, that the final product will be something we're all proud of at the end of the day. I can't say for certain if that will be the case, if I could tell the future I'd buy a lottery ticket, and I wouldn't care about programming or at least working to pay my bills that is. At the end of the day I don't speak for Microsoft, just myself. Back when ASP.NET vNext broke visual studio integration (beta 4 maybe? I dunno that was a long time ago) was the day where my eyes opened to a world that didn't revolve around Visual Studio, and that was a great day. That's what grew my passion for Open Source and while I can't commit as much time as I want to things these days, I do still think that what we have is special, and I really hope that when the dust settles we will be in a better place than we started. |
|
What was the issue in being a good open-source citizen and contributing time or money or both into the existing omnisharp project, maybe a vNext? Would have likely earned goodwill from the .net community. I know the C# support in vs code is non-optimal for me as an end-user, so I guess I can see the positive in this move towards introducing better support. |
|
A platform is as open source as its tooling. VSCode is open source is the greatest wool MS pulled over everyone's eyes. Still we had VSCodium, but then MS took over Omnisharp and tried to break that (.Net Debugger is not open source and won't work in VS Codium explicitly). I tried to use VSCodium to create a simple .NET project on a non-Windows OS and struggled hard. So basically .NET is as open source as Windows is 'free', but bring in those sweet govt. contracts!!! |
|
@glennawatson perhaps the issues with C# support in vscode are more to do with a not-accidental lack of investment leading to the exact situation we're in now. F# has a really good experience in VSCode and was basically done by two people in more or less their spare time. It shouldn't have been this hard to get a good C# story in VSCode all this time. |
When heavy lifting is done in closed source software, performance fixes become a cost center for msft and the vscode experience for C# ends up the same as visual studio. If they are worried about some other corporation copying it they should just license it as GPL. |
|
There are multiple reasons for why the lives of .NET developers will always suck: First of all every division at Microsoft needs to be cash positive. At DevDiv (developer devision) the main bread maker is Visual Studio. .NET is free and makes no money. VS Code is free and makes no money. OmniSharp is/was free and made no money. ASP.NET is free and makes no money. It's mostly SQL and Visual Studio licenses which pay the salaries of the .NET team. For that reason Microsoft can never let it happen that a free and open .NET extension can make VS Code a good enough experience for the vast majority of .NET developers. It's not by accident that despite Microsoft owning C#, .NET, VS Code and OmniSharp the C# experience on VS Code was the worst of its kind in comparison to any other programming language. It's by choice in order to push developers to use Visual Studio. Another big reason is that Microsoft needs to keep a tight grip around their .NET developers, because .NET is the main driver to Azure adoption. Azure is an extremely unattractive product to any other development community. Azure is slow, it breaks, it over promises and under delivers and it is almost twice as expensive to AWS or GCP once you actually establish feature parity. It's mainly .NET devs who get cleverly pushed to Azure and siloed away from anything non-Microsoft by Microsoft. The world runs in the cloud nowadays and the cloud is a unix based environment. Microsoft has felt the bleed of its traditional Windows centric developer base migrating away to macOS and Linux and becoming more wise about their technology choices. In order to stop the bleed Microsoft tries hard to convince its remaining Windows developers to remain in the Windows/Azure silo by giving them just enough sugar coating so they never step outside. WSL, the new unix-like terminal in Windows, Windows containers, etc. are all attempts to keep Windows folks on Windows and therefore closer to Azure. The irony with all of this is of course that if you are a software developer, you'll have a MUCH MUCH better experience with Microsoft owned products (GitHub, VS Code, etc.) if you choose any programming language which is NOT .NET, because (at least for now) they will not try to come after you to lock you into their Windows/Azure based silo. For instance take GitHub Co-Pilot as an example. Microsoft made it available to JetBrains IDEs for every programming language except .NET. Initially the GitHub team was forced (by DevDiv management) to implement a switch so it can be disabled for Rider, effectively making GitHub Co-Pilot only unavailable to .NET developers unless they use Visual Studio. Luckily there were some other forces at play which ended up reverting this switch, but it's a great example where Microsoft is prepared to harm only .NET developers and no other community in order to keep them locked in. My advice is to pick a different programming language if you want to be truly free and have fun writing code. We all became programmers because we have a passion for writing code and nobody wants to deal with this BS if there are so many options available that make life as a developer easier. EDIT: People are asking why would Microsoft harm itself in the long term like this? The truth is they have no choice. Microsoft currently struggles to compete based on merit. The big fear is that if .NET developers become free spirited cowboys like the JS or Go or Rust or Java community then they will slowly start exploring products outside the Microsoft ecosystem. It starts small and then snowballs from there. If .NET devs start deploying more to AWS then new hires will come from the AWS community. Those new tech leads/CTOs/etc. will also have more experience with other non Microsoft technologies and possibly migrate long standing Microsoft shops further away from the traditional Windows/Azure/Office/SharePoint stacks. So what does Microsoft do in order to prevent this from happening? Bundle everything so people find it harder to convince themselves to explore other tools. Give things away for free which otherwise couldn't compete based on merit (e.g. Teams vs Slack/Discord). Deeply integrate Office into Windows, bake Teams into the start menu of Windows 11, give users 20 prompts a day to install Internet Explorer Edge or to use Bing. Even if you change your default browser settings Windows will open every URL from within Windows in Edge and plaster Bing search bars everywhere so users end up using these things even if they don't want to. The goal is of course that at some point users will give up and just adopt the Microsoft tools because it gets too tiring to fight against it. It's a good enough strategy to keep people locked into the Microsoft system until they find a way to make their products so good that people want to use them. It is the same with .NET and Visual Studio and Azure. Microsoft cannot control Rider so Rider eating huge shares of the .NET IDE market is a big problem. JetBrains has no stake in Azure so they will not actively promote deployment options or project templates which are geared towards Azure. VS Code is owned by Microsoft but they cannot exert their power as freely with Code as they could with Visual Studio. If Code was to ignore people's default browser setting then all the non Windows and non .NET developers who currently use Code would quickly leave that IDE. Same if Code was to bake Azure features everywhere into the product people from Java, Go, JS, Rust, PHP, etc. would get pissed off and leave. So in terms of Code Microsoft rather plays nicely with all those communities just to keep them a bit closer to themselves and at least collect a lot of intel on them with forced telemetry. However, they can make the .NET experience on Code extremely lacking in comparison to Visual Studio and then advertise Visual Studio as the best development experience for C#. In Visual Studio Microsoft can do whatever they want and heavily push their own products down on unsuspecting C# developers. This is the strategy and no complaining on this GitHub issue or anywhere else will change that, because Microsoft has no option. |
|
I raised the |
|
It's this another Liuson scheme? Who is responsible for this kind of nonsense and why aren't people like Scott Gu or others (@ahejlsberg @MadsTorgersen) saying something about the blundering and brand/trust capital being lit on fire? I think it's time that people who know that what's going on is long-term suicide start throwing their weight around in the company. Like seriously. Pick up the phone or write an email to Satya at this point guys. There's a loose cannon in the company somewhere who is totally misaligned with what has been working up until now. |
|
🆕 https://isdotnetopen.com/ has been updated to track this.
See also dotnet/core#505 |
|
Hi everyone, apologies, I just posted an update above to hopefully make clear some things that weren't. Please see update in the original post. Putting here in case only reading replies as well Thanks for the passionate feedback. I’d like to clarify a few things stated in the feedback that we failed to make clear. The LSP implementations for Razor and C# will remain open-source (Roslyn and Razor) as they are today. The VS Code C# extension (ms-dotnettools.csharp) itself will also remain open-source. That which is open source today remains so and in active OSS development. This ensures that others outside of VS Code that use LSP continue to have access to C#. This new host component is the bridge between open and closed source functionality letting us deliver both at the same time. |
|
close source is close source, don't mixed close source and open source .. |
|
@timheuer I don't think it's that your messaging was off, or at least if it was, then it was not in a way that could be meaningfully avoided. Tooling is often essential to make a business run, and if you don't have the ability to fix, modify, or extend that tooling, it's often worse than features simply being absent. If a closed source feature is causing problems for me, I'm going to just have to deal with it. That's simply not a competitive offering for developer tooling. I'm happy and eager to pay for good software. I'm not opposed in any way to LSP, but I am worn thin by dealing with software that "can't be fixed" and who knows what it's doing to your machine. |
|
You can just... use editorconfig to set any formatter options, instead of vs options. if you have vs with non standard options or defaults differ, you can make vs generate an editorconfig. both vsc and vs respect it for projects containing it. |
|
In terms of format tooling, I hate that Csharpier is not compatible with standard And that's not to say that Omnisharp based formatting is enough, even with |
|
pretty sure omnisharp based formatting is same as vs. note that it's not omnisharp formatting, it's roslyn itself. |
You are right that Onnisharp formatting is Roslyn really. But I think VS has more formatting capabilities than just Roslyn. |
|
Interestingly, it doesn't, from what I know of. |
Omnisharp too bad for c# in vscode |
|
According to #5705
the new language server will be fully open-source 🎉 |
|
The only problem is that new C# extensions https://marketplace.visualstudio.com/items?itemName=ms-dotnettools.csharp and https://marketplace.visualstudio.com/items?itemName=ms-dotnettools.csdevkit are not open-source (at least for now) |
|
|
The new official announcement is here: #5708 I don't think they lie about is being open, but I can't find the source code of the new "LSP Host" either. If anyone knows, posting here a link would be appreciated. |
|
I think it should be either a part of new extension codebase or the Roslyn itself. I think we should wait for the nex anouncement in June 13 |
|
Hi all, please see an update here: #5708 -- FYI the repo is in the process of being moved this week and requires a bit of coordination we didn't align just quite in time today. Please know we're working on migrating the source to the repo identified in this update. |
|
Thanks a lot for the great work. It's also amazing to see the C# Dev Kit announcement mentioning debugging, another key area that could use some love. I have a question if you may. Is IntellliCode supposed to work side by side with GitHub Copilot? In the past they seemed to do pretty much the same thing, so I kept only Copilot, but this seems different in the context of C# development. UpdateI moved my question to the new thread. |
Just a correction -- the ms-dotnettools.csharp one is this repo and that is the OSS one. |
This is the repo where it will be at -- we are in the process of moving the code from internal repo to here...might take us a week to ensure we have the infrastructure moved for build/release. |
|
Cool beans |
@exyi: The LSP server itself is being made public in dotnet/roslyn#68461 and should merge into Roslyn in a day or so once some other internal infrastructure gets working. The changes in this repo to launch that LSP server we should get posted in a day or two. |
|
A couple of questions about the new changes in regards to other editors (ex. nvim):
|
The LSP host is something roslyn is building, and is intended to be licensed the same way roslyn is licensed. We have a couple of minor snafus in the licensing being totally correct there, but we should be able to get through all of that in the short term. This code will be just a normal library/exe that you can use based on the roslyn license. :) From the Roslyn perspective, we want this to be a high quality, scalable, efficient, compliant impl of the LSP protocol on top of C#. Our hope is that people find value and use for this in whatever domains they'd like it for :)
There's been no change around the debugger licensing currently. Sorry! |
|
Note: you can see the server here: https://github.com/dotnet/roslyn/blob/main/src/Features/LanguageServer/Microsoft.CodeAnalysis.LanguageServer/Program.cs ! :) As per above, this is all part of our Roslyn OSS story, and delivering a high quality LSP server impl deliverable as is a core part of that story we are committed to. If you run into issues with this server, def let us know as we expect some small growing pains as this is adopted broadly, and we want to fix those problems quickly :) |
Is there a reason the Debugger can't be made to use in any editor given you have a paid subscription to say Visual Studio Professional? |
|
What is the status of "Update the C# for VS Code extension to communicate with OmniSharp Server via LSP by default."? In my experience the new Roslyn LSP is quite broken and reverting to "OmniSharp" seems to fix most issues, but the recommendation is to disable the C# Dev Kit extension. I did find that using the options "dotnet.server.useOmnisharp" and "omnisharp.enableLspDriver" seem to work well even with "C# Dev Kit" still enabled. I assume that combination of config is an experimental version of the feature you mentioned. Is there a roadmap to make that the default config, or otherwise not be marked as "experimental"? |
@TrieBr do you believe the issues you are experiencing are reflected in open issues right now? If not, I'd love for you to open individual issues where things are still broken for you. With regard to the direct question, tagging @arkalyanms on implementation details/timelines |
|
I suppose my main complaint aside from crashes that break intellisense altogether is with Razor / Blazor. I've been waiting for years to get proper Razor / Blazor intellisense in VS Code, and eventually gave up and went to Rider. However recently I came back for another attempt (years after the move to the new LSP) and find that Razor / Blazor support is still weak or completed broken, as evident by many lingering issues (examples below): #6921 So I suppose that yes my issues are reflected in open issues, but there doesn't seem to be any improvement despite being a constantly reported issue. I'm pleased to see @ryzngard seems to be looking into these issues recently. However I'm still curious if there is any plans to better support "Omnisharp with LSP" in the meantime or if I should stick with Rider longer. |
Omnisharp over LSP is on the back burner at the moment and we do not have an estimate of when that will come back up. I will report back when know timelines. In the meantime, if there are quality concerns with the Roslyn over LSP model, those are much shorter strides to take and can be funded. Aside from the razor ones above, if there are intellisense concerns on C#, do feel free to tag me on those as well and we ll prioritize those. |
and others
Over the past several months, the .NET team has evaluated ways to evolve the .NET tooling ecosystem and incorporate more capabilities into VS Code. Currently, the C# experience in VS Code is powered by OmniSharp. This is thanks to the leadership of Filip Wojcieszyn, David Driscoll, Martin Björkström, and also, Jason Imison, who originally started the OmniSharp project over eight years ago. OmniSharp generated a lot of excitement by bringing the C# experience to VS Code, using the APIs and protocols that were available at that time. VS Code has since matured and today, the Language Server Protocol (LSP) has become the standard mechanism through which modern developer tools speak to one another. We believe that moving the C# extension to LSP will help us accomplish our goal of creating an extensible and flexible tooling environment which easily integrates new experiences into C# for VS Code.
As we move towards a more dynamic future for the C# experience in VS Code, we intend to switch the extension to communicate entirely using LSP and plan to update the existing OmniSharp component to communicate in this manner as well. Utilizing LSP will allow us to bring innovative new features to the C# for VS Code extension. This includes making advanced capabilities available and, in some cases, closed-source experiences, such as IntelliCode. We plan to create a new “LSP Tools Host” component (not an official name 😊), which integrates both open-source components, like Roslyn and Razor, with closed-source components, offering a wider array of tooling capabilities.
Once the “LSP Tools Host” is complete, this will become the default experience for the C# for VS Code extension. Existing users will be able to choose between the open-source OmniSharp powered system that exists today, or the new “'LSP Tools Host” which will provide access to additional experiences. The “LSP Tools Host” will not be open-sourced, but we plan to communicate with the community along the way to help guide our future plans.
We'd like to again thank everyone at OmniSharp and all the contributors to this project for doing such an incredible job in helping to bring the C# developer experience to VS Code. We have been collaborating with the OmniSharp team and will be working with them to ensure that this process is smooth, and plan to work with them, as well as the broader community, in order to drive forward this exciting new future for .NET tooling.
Next Steps (these will ideally be issues that will be trackable, timelines of these may vary)
UPDATE:
Thanks for the passionate feedback. I’d like to clarify a few things stated in the feedback that we failed to make clear.
The LSP implementations for Razor and C# will remain open-source (Roslyn and Razor) as they are today. The VS Code C# extension (ms-dotnettools.csharp) itself will also remain open-source. That which is open source today remains so and in active OSS development. This ensures that others outside of VS Code that use LSP continue to have access to C#.
This new host component is the bridge between open and closed source functionality letting us deliver both at the same time.
The text was updated successfully, but these errors were encountered: