Announcement: A roadmap update on the VS Code C# extension

[timheuer]

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 the C# for VS Code extension to communicate with OmniSharp Server via LSP by default.
• [x] Switch the C# for VS Code extension to use the new “LSP Tools Host” by default and allow users to choose an alternative language server.
• [x] Ship the C# for VS Code extension with these new defaults bundled with more features “out of the box”.
• [x] Move the C# for VS Code extension from github.com/OmniSharp/omnisharp-vscode to github.com/dotnet/vscode-csharp and have Microsoft keep this up to date and ship it. This move will enable us to easily integrate and reuse the existing dotnet infrastructure assets, like our shared building, testing, and publishing system, and will reduce overall engineering costs.

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.

[GerardSmit]

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:

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.

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?

Switch the C# for VS Code extension to use the new “LSP Tools Host” by default and allow users to choose an alternative language server.

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 dotnet watch (https://github.com/dotnet/sdk/issues/22247)).

The Language Server Protocol (LSP) has become the standard mechanism through which modern developer tools speak to one another

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 vscode-csharp is mentioned), so once LSP Tools Host gets full attention, OmniSharp will slowly die out (especially if the OmniSharp team is working on LSP Tools Host). Which is of course the last step, extinguish.

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.

[mhmd-azeez]

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

[jasiozet]

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.

[nyeogmi]

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!

[flibitijibibo]

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.

[codymullins]

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.

[voronoipotato]

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.

[ssg]

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.

[PJB3005]

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.

[sid-6581]

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.

[thatcosmonaut]

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.

[pekseneren]

Microsoft should end the production race between VS Code and Visual Studio for good.

[voronoipotato]

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.

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.

[jsaunders92]

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?

[david-driscoll]

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 dotnet watch (dotnet/sdk#22247)).

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).

• The big one being I still want there to be an easy way for other editors outside vscode to have access to C# (emacs, vim, anything that supports LSP really).
• Another being the open source nature, fundamentally if the final product is not open source or at least a good portion, it will really be problematic for the community (I have all said as much). I expect things like the debugger to be closed source because that is tech Microsoft wants to control the license of, as we've seen with Rider years ago.

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.

[david-driscoll]

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:

• .NET Core being a thing is awesome - Back when I first tried ASP.NET vNext I couldn't believe they would make such a move.

The bad:

• dotnet watch - I don't really need to comment more.

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.

[glennawatson]

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.

[sumitkm]

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). VS Codium + OmniSharp + Samsung Debugger just about works no thanks to Microsoft.

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!!!

[isaacabraham]

@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.

[voronoipotato]

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.

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.

[dustinmoris]

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.

[rgwood]

I raised the dotnet watch issue last year, and I get the impression that not much has changed since. The decision to keep this closed-source is disappointing but not surprising; Developer Division leadership is still making decisions that are not aligned with the long-term health of .NET.

[atrauzzi]

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.

[ghuntley]

🆕 https://isdotnetopen.com/ has been updated to track this.

"After last year's debacle, I authored a paper to address the question "What should we do instead of shooting ourselves in the foot?" - now we know, it soared like a lead balloon." - https://twitter.com/migueldeicaza/status/1537178691218046976

"Everyone I admire in DevDiv opposes these terrible ideas, including Tim." - https://twitter.com/migueldeicaza/status/1537214636126347265?s=20&t=lVDtlWpXFdJahKccug2dNQ

See also https://github.com/dotnet/core/issues/505

[timheuer]

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.

[ghost]

close source is close source, don't mixed close source and open source .. I hate all action looks like : mixed fake open source with really close source . Mother fuck indeed.

[voronoipotato]

@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.

[ghost]

1. I support microsoft can sell and user can pay for good tools.
2. May this software be released source code under GPL ? [ to protected your rights]
3. OSS is good better than close source , any one can report issue, join the development , write test cases.
4. don't go from OSS to close source. and welcome go from Close source to OSS.

[ghostbutter-games]

Stuff like this and the dotnet watch debacle happening far too often is the reason why I chose not to commit to .NET and spend my efforts elsewhere. Microsoft seems to be completely divided between the (mostly brilliant) engineers and the toxic marketing and business people.

What a huge waste of time & disappointment for everyone who put their heart and soul into an open .NET.

[phillip-haydon]

This new host component is the bridge between open and closed source functionality letting us deliver both at the same time.

How about, maybe, you just make it all open source, and stop playing games. You're not going to benefit AT ALL making it closed.

Look at .NET as a whole, look at how much has improved by making it open source, people contributing bug fixes, performance improvements, feedback.

Why would you give 2 shits if your host component is used by someone else in another IDE. Not everyone likes VSCode, but maybe the host would be useful in Sublime Text, or Brackets, or some banana IDE. And it brings more people into the .NET eco system who deploy to AWS because MS is too focused on crippling everything and pissing everyone off rather than focusing on making Azure a worthy place to deploy to.

[ultimaweapon]

I thought Microsoft has been learning from the dotnet watch issue from the past but it seems like it is not. Now they try again with C# extension.

I am already disappointed with the C# debugger on VS Code. Now I can decide that I'll move to another stack for all of my work and switch to VSCodium.

[peppy]

If keeping certain components closed source is about money, please consider giving us a way to financially support the .NET ecosystem. Something like .NET foundation but without the corporate wank.

It doesn't have to be a constant tug-of-war, I think the majority of .NET developer would be willing to contribute back financially to keep things going and keep .NET usable on all platforms and IDEs without seemingly arbitrary marketing-based restrictions.

Signed someone who has used .NET primarily since printing out the original multi-hundred-page language reference in high school.

[exyi]

This new host component is the bridge between open and closed source functionality letting us deliver both at the same time.

It's not only a bridge if it will be the primary LSP VS Code will use, right? Why do we even need the closed source components? I'm afraid this means that OmniSharp will receive much less maintenance work, new C# / .NET features won't work and we'll be eventually forced to use the proprietary "LSP Tools Host".

[glennawatson]

I imagine the closed source element will be code from visual studio to get a new component out and iterated faster. MSFT employees would likely have to go through internal approvals from lawyers and executive teams to release to the public which isn't instant in a company that size.

[sid-6581]

I imagine the closed source element will be code from visual studio to get a new component out and iterated faster. MSFT employees would likely have to go through internal approvals from lawyers and executive teams to release to the public which isn't instant in a company that size.

If that's the case, that seems like a simple enough thing to include in the original statement. Instead we got basically no explanation of what exactly was going to be closed, or why. Even the update doesn't really clarify much. The vagueness is the biggest problem here.

[maxkatz6]

While I am not happy with closed source components, currently VS Code C# coding experience is way behind of VS or Rider. If this idea will improve current situation (for instance speed up porting of components from the big-VS), that's probably for better.

[aL3891]

Assuming that this host is really just a "bridge between open and closed source functionality" what can it possibly contain that would motivate the PR/optics disaster of making it closed source? Either you're withholding something from the community or this is just a terrible call by someone very out of touch.

If you are going to undermine all the people who evangelize Microsofts open source efforts, try and convince people like dustinmoris that dotnet and microsoft products are worth their time, it should be for a very very good reason. And i dont think you have given that

i'm not against closed source for features like intellicode, but the infrastructure, especially new infrastructure should be as open source as possible, and if not, a very clear reason should be given why..

[phillip-haydon]

I imagine the closed source element will be code from visual studio to get a new component out and iterated faster. MSFT employees would likely have to go through internal approvals from lawyers and executive teams to release to the public which isn't instant in a company that size.

This is now less about something requiring approvals and signoff and more to do with trying to control the eco system. MS wants everyone to use their tooling, not other peoples. This would most likely result in them being about to push a feature to Visual Studio and VSCode concurrently while making Rider look like its behind in terms of new features.

[mika76]

@timheuer could you be more explicit what features would be closed source? The only one mentioned by name so far as I can see was intelli-code (which omnisharp does not currently have anyway right?)

Will there be any features of omnisharp converted to closed source or are these only new features?

Also where does hot reload stand in this case?

[dodyg]

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.

Why combine it? If you want to offer a wider array of tooling capabilities, you can simply create another extension and market it as "Microsoft Super Advanced Extra Visual Studio Code Extension". Keep the basic open source and don't muddy the water.

[dadepretto]

I’m “forced” to use JetBrains Rider on non-Windows OS for .NET development, and I was so excited when I heard a hint during Build about improved support for C# in Vscode (which I love). This whole debacle is frustrating for me, especially after the great success of .NET as an open-source platform. I hope MSFT will get its things together and do the best for the community.

[pradyunsg]

FWIW, this looks eerily similar to how Microsoft handled their Python extension, gaining popularity on the back of an open source solution (Jedi). Then building an LSP-based proprietary extension (https://github.com/microsoft/pylance-release), with the promise of a better UX and then making the closed source solution the defacto default (even pushing prompts to switch to it in the editor UI), while reducing the development resources they put toward the non-proprietary solution.

Today, using the Python extension with Pylance has objectively more features than with Jedi. Switching to Jedi disables many genuinely useful features.

If that’s how this is going to play out, I’m guessing that no amount of pleading or whining about the purity of open source being important to you is going to matter — there’s precedence for this model working out positively for Microsoft, enabling proprietary components where Microsoft keeps the IP around the actual IDE experience away from potential competition in the space, while still being able to say “open source” in all the marketing materials for VS Code and meaningfully improving the extension’s functionality.

[goofballLogic]

Have you learned nothing? You have earned some trust but not enough to do this. Leave the closed source components out of it.

[vjos]

Classic M$ move

[poke]

What frustrates me about this is that Microsoft expects the community to do work in the open, with all the known struggles of open source maintainership but instead of going that route too, they just rather move to closed source.

We have projects like Duende’s Identity Server or ImageSharp that do want to develop in the open since it's a beneficial thing for the whole community. But that's difficult to finance so they keep trying to come up with solutions to make it sustainable.

And here we have Microsoft that instead of joining these people and using their power to improve the sustainability as a whole, they just take the easier road and make it closed source.

Okay, parts of the new extension are a “secret sauce” and shouldn't be usable by competitors, or maybe should be paid features. Then why not go the route that the Open Source community has to go and protect it with licenses in the open? Sure, that will be more difficult to enforce but everyone else has these problems too. But it would also be probably easier for Microsoft too and they could lead as a great example for the community.

[Atulin]

First it was the debugger, then it was the hot reload, now the VSC plugin...

What next? Roslyn Pro compiler with Office 365 subscription?

[PathogenDavid]

I get that Microsoft doesn't want to give away IntelliCode, but why does the LSP Tools Host need to be closed source?

It seems weird to me to have a closed source component sandwiched between open source layers. Why can't IntelliCode be a closed-source component to an open-source LSP Tools host?

[WhiteBlackGoose]

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

It seems like O# users shouldn't really care much, as nothing changes for them (and it's even promised that O# will be developed faster). So all MSFT is doing is just adding its own solution, without harming the existing things, is that correct?

[sumitkm]

I am already disappointed with the C# debugger on VS Code. Now I can decide that I'll move to another stack for all of my work and switch to VSCodium.

Haa haa... don't even think of switching to VSCodium, nothing .net works straight in VSCodium because the debugger is scuttled so VSCodium is even less functionality!!! You can install OmniSharp vsix and install it manually but then you have to go get a Samsung debugger because MS debugger is only meant for MS tool... (yeah Code is open source, my ....)

[pjmlp]

These are the kind of decisions that kill all good will on the FOSS community to pick .NET versus other language ecosystems.

Apparently management still hasn't gotten it.