Announcement: A roadmap update on the VS Code C# extension
timheuer opened this issue · 322 comments
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.
- 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.
- Ship the C# for VS Code extension with these new defaults bundled with more features “out of the box”.
- 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.
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 (dotnet/sdk#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.
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.
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.
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?
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.
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.
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).
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!!!
@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.
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.
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 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.
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.
"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 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 ..
I hate all action looks like : mixed fake open source with really close source .
Mother fuck indeed.
@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.
- I support microsoft can sell and user can pay for good tools.
- May this software be released source code under GPL ? [ to protected your rights]
- OSS is good better than close source , any one can report issue, join the development , write test cases.
- don't go from OSS to close source. and welcome go from Close source to OSS.
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.
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.
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.
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.
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".
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.
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.
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.
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..
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.
@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?
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.
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.
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.
Have you learned nothing? You have earned some trust but not enough to do this. Leave the closed source components out of it.
Classic M$ move
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.
First it was the debugger, then it was the hot reload, now the VSC plugin...
What next? Roslyn Pro compiler with Office 365 subscription?
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?
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?
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 ....)
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.
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?
Considering Microsoft's past actions, it is very probably not the case.
If you don't create closed source components you don't need a bridge to open source ones. [smartguy.gif]
Considering Microsoft's past actions, it is very probably not the case.
@Speykious what are you referring to? When did it harm some already existing FOSS project?
Considering Microsoft's past actions, it is very probably not the case.
@Speykious what are you referring to? When did it harm some already existing FOSS project?
- When they tried to remove
dotnet watchfrom the OSS. - The situation with the Python language support mentioned earlier in the thread.
Even if the support for the current OmniSharp solution remains in place the concern is that it will hinder the developer resources poured into supporting it (whether by Microsoft, Microsoft employees in their spare time, or anyone else).
There’s an interesting discussion thread regarding this decision on Hacker News https://news.ycombinator.com/item?id=31762778.
Considering Microsoft's past actions, it is very probably not the case.
@Speykious what are you referring to? When did it harm some already existing FOSS project?
Pretty much what @filipnavara mentioned above. I could also mention the recent sunsetting of Atom, though maybe it's less relevant.
Considering Microsoft's past actions, it is very probably not the case.
@Speykious what are you referring to? When did it harm some already existing FOSS project?
https://github.com/mono/monodevelop, which is now Visual Studio for Mac.
When Mono joined the .NET team, they've added private NuGet repositories which caused the project not to build anymore. In the end, they've archived MonoDevelop and is now fully closed-source.
When they tried to remove dotnet watch from the OSS.
Right... from what I understand, they intended to ship it later after .NET 6 is out, but I might be mistaken.
The situation with the Python language support mentioned earlier in the thread.
That seems fair.
Right... from what I understand, they intended to ship it later after .NET 6 is out, but I might be mistaken.
That's gross misunderstanding of what happened. It was intentional removal of a feature in order to support it only in a proprietary closed source product. You can try to put a lot of marketing lipstick on that proverbial pig but it's still a pig. I made my point earlier by forking the perfectly working dotnet watch code into an OSS tool. I don't want to reopen wounds though.
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?
The closed source solution becoming the default only pushes people away from Omnisharp. Instead of helping one of their open source tools, Microsoft decides to introduce a closed-source rival, all that effort put into creating "LSP Tools Host" could be spent improving and extending Omnisharp.
Why should any of the LSP Tools Host features be exclusive to it? Why should LSP Tools Host be closed source?
Okay, I agree that so far it looks like a dick move. Not inheritly evil in the sense, that everyone instead of MS could create a proprietary extension and theoretically compete with O#, and nobody would be mad with that. But the fact that it's done by MS is a bit 🥴
Considering Microsoft's past actions, it is very probably not the case.
@Speykious what are you referring to? When did it harm some already existing FOSS project?
The debugger. I don't think it was exactly OSS, but the license was at least more permissive.
Then it changed, to the degree JetBrains had to write their own to include it in Rider.
Do better Microsoft. There is absolutely zero reason to keep any part of VS Code closed source and absolutely zero reason to replace existing open source components with closed source alternatives.
The goal is to get developers working within your tech stack and keep y'all relevant, is it not? VS Code and .NET Core did that for me as I long ago decided I was done with Windows. These tools allowed me to keep working with .NET outside of the Windows ecosystem and allowed me to keep making productive use of my .NET knowledge on far less objectionable operating systems.
Moves like this only encourage the naysayers that have been waiting in the wings for y'all to screw up like this to say, "Oh look, Microsoft eventually screwed you all over, see?"
Prove them wrong. Be better than this.
@jaylittle As I understand, this isn't about VSCode but an extension for it. It's a new extension and some proprietary bits that also exist in VS will be closed source.
@jaylittle As I understand, this isn't about VSCode but an extension for it. It's a new extension and some proprietary bits that also exist in VS will be closed source.
This is an extension that Microsoft wields a ton of control over and is core to the C# development experience in VS Code... so this may as well be about a core component in VS Code in that respect.
As someone that runs Linux, C#/.NET development with Vim has been horrendous, in contrast, Go and Python development is a joy.
After the dotnet watch debacle, I started learning Go, I started having doubts about Microsoft and this decision affirms my doubts. I am glad I'm slowly moving away from C#/.NET. Well done Microsoft 👎
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
-- @phillip-haydon
The irony of someone complaining about a completely open source project making one component closed source hurting a completely paid product like sublime 🙄 as well as a discontinued website (Banana IDE).
I don't even think that's the ideal play. Desktop tools are going to zero. If you're not Web based, you're dying. The only real competitors to Microsoft for developer tools in 10 years will be GitLab, BitBucket, JetBrains' Space Program and AWS XRay, and they will be competing against GitHub Codespaces. The first company to crack immersive, secure code text editing will have a huge advantage, as Visual Studio LiveShare still leaves much to be desired. In that sense, it is entirely possible the host component will play a key role in securing and optimizing the user experience.
Please reconsider. These are the actions that drive people away from the platform, not in.
Last Tuesday, I made a talk about showing all the benefits of FOSS and how to have a clear FOSS strategy from a mostly closed source company. I took Microsoft as an example. Please fix this issue so I don't have to edit my slides to remove you.
I'd appreciate an explanation from folks with the ❤️ on the OP; am I truly missing some subtle thing we should all be celebrating here?
Or is this some new form of sarcasm or dead man's switch?
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
-- @phillip-haydonThe irony of someone complaining about a completely open source project making one component closed source hurting a completely paid product like sublime 🙄 as well as a discontinued website (Banana IDE).
It doesn't just hurt Sublime as a proprietary product. It hurts the developers who would like to use tools they're comfortable with when working with .NET but can't because the experience is far inferior.
It locks you into a platform, it gives you less choice as a developer and it also makes development more expensive as you're forced down the path of using Visual Studio which translates into a lot of money spent on licenses.
It also does hurt people trying to use open source tools such as the fully open source builds of VS Code (VS Codium), the MS C# extension's debugger refuses to work with builds of VS Code that aren't from Microsoft.
as well as a discontinued website (Banana IDE).
For what it's worth I didn't even know there was an ide called Banana IDE until I googled just now seeing your comment.
closed source hurting a completely paid product like sublime
Why does it matter if Sublime Text is paid for, insert any IDE with plugin support. I just picked ST since it already supports OmniSharp, but we can more or less kiss that goodbye if this change goes ahead. Anyone who prefers ST wont be doing .NET work anymore.
If you're not Web based, you're dying.
No one wants to spend their entire day coding in Chrome. What a terrible experience. Maybe when browsers are not so clunky and brittle it maybe an acceptable experience. But it wont be cracked anytime soon.
GitLab, BitBucket, JetBrains' Space Program and AWS XRay
AWS XRay is a debug/tracing service, unsure what it has to do with any of the others you mentioned. Yes GitHub is playing catch up after MS's more or less failed with Azure DevOps. But you don't need to create a walled garden to compete. You have to make a better service, better experience. Not pissing off your community with your 2000 era dance moves.
Not again... there is clearly some conflict of interest at Microsoft between “C#/.NET/framework people” and “Visual Studio/VS Code/tooling people”. The truth is that platform is not truly open-source without it's tooling and these decisions are hurting whole dotnet community and are discouraging new developers from adopting the platform.
In the past I believed the whole “Microsoft embrace opensource because now they earn most money on Azure and they embrace the fact that you use free and open source stuff because they just want you to use their cloud services” mantra but it's clearly not true now (and probably never was).
After "dotnet watch controversy", as a form of protest, I decided to avoid Microsoft IDEs for .NET development. I've been happy with Rider ever since. I recommend everyone to follow similar path. Maybe when Microsoft will see they lose money on classic (not web/remote) devtools and IDEs, they will get their shit together.
No one wants to spend their entire day coding in Chrome. What a terrible experience. Maybe when browsers are not so clunky and brittle it maybe an acceptable experience. But it wont be cracked anytime soon.
...and somehow it's fine when VS Code is running on Electron, which runs on Chromium engine? Remember, this issue is about VS Code extension in the first place.
This is already happening whether you realize it or not. There's vscode.dev, GitHub Codespaces, GitPod.io, and others. Of course there are still things that haven't been fully cracked yet, like moving the mobile or desktop development experiences into these cloud environment, but it is happening (https://marketplace.visualstudio.com/items?itemName=unoplatform.vscode).
I only started using the cloud IDEs recently and while they are not perfect the fact that you can use them on any device at any time makes a huge difference in productivity. The fact that it comes with prebuilt (Docker) images with all the right tools already installed makes it far easier to on-board than traditional desktop experiences. It also makes it significantly easier to keep all the tools updated or fixed to a specific versions.
Most importantly, the OP announcement can hurt GitPod.io and other competitors who use custom VS Code builds. If you restrict their access to the closed source part you end up with preferential treatment for first party offerings (GitHub Codespaces) and drive the competition to extinction. They wouldn't lose access to OmniSharp but they would lose the 16M users that drive the improvements in OmniSharp and make it viable to contribute to it.
...and somehow it's fine when VS Code is running on Electron, which runs on Chromium engine?
VS Code currently using 180mb of ram. Chrome using 3.2gb...
...and somehow it's fine when VS Code is running on Electron, which runs on Chromium engine?
VS Code currently using 180mb of ram. Chrome using 3.2gb...
Compare Apples to Apples
This is Edgium/Chome with only https://vscode.dev open:
This is VS Code process with no project loaded:
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.
I was warming up to .NET after having been a skeptic for years. Particularly F#. I'm jumping ship now. OCaml 5 preview just got announced and F# is "basically" a .NET OCaml. I'll go to Crystal for my OOP or Ruby.
Why invest into an ecosystem where this kind of behaviour occurs?
Honestly, I don't use vscode that much... but my perspective on this one is that people that work so hard to get .net adoption, and to inform others about the amazing project .net core has made in the last 5yr are having their efforts undermined by efforts like this. As much as I've preached and shown how much of .net has gone opensource and how its not closed... only to have these things go closed source.
Help us help you.. .or better help us help .NET
....
This new host component is the bridge between open and closed source functionality letting us deliver both at the same time.
...
What a betrayal for the comunity. Really awfull.
F# is "basically" a .NET OCaml.
@tsujp Not really and tooling in F# has a different story it has been open for a while, as Isaac mentioned above in the thread vscode tooling for F# is actually decent. There's a core component (FSAC) that all of the major (VS, Rider, Ionide) and other (vim, emacs) players actually benefit from.
Here's the thing though the vscode tooling is mainly community driven in F#, are C# devs interested in the same kind of investment or they just turn the eye to Rider/VS or just wait for Microsoft to do something?
I'd say it is the last option as usual
My main puzzling question at this point is: Why has not the C# community take over ominsharp/forked it and continue its development to be a top notch open source solution after years of complaining and stalled development?
this issue comes out and suddenly omnisharp is very important and we should protect it over everything
Why has Microsoft have to do everything here?
The people who win/lose here IMO (in addition to Dustin's comments about how everything is made to keep you in the azure/windows loop) are very likely indie devs who are experimenting with C# they either get a sub-par experience with omnisharp and leave or get a very likely better experience with this new closed component, the rest of the C# community can simply wait (as they've been doing for most of the time) for Rider/VS to provide tooling
I think this is just another case of the unwillingness of the C# community to do something and just wait for Microsoft to do something and when Microsoft does something everybody just rages for the sake of raging, arguably this is backed by the fact that one would hardly ever want to compete vs Microsoft (thanks dotnet watch, appget, dnf, and others) but it also speaks volumes of the community around .NET unwilling to take leadership and unwilling to accept current leadership decisions
@AngelMunoz I agree with your sentiment. Open source is not free--someone is always footing the bill either in time, money or both. I this case, MS has spent a tremendous amount on the .NET ecosystem, but at the end of the day they are a business and have to balance their needs in that regard. And they have a right to do so since they own these projects. All I see is a lot of entitled complaining from some in the community, but no willingness to step up and support the open source effort by taking on a better alternative.
F# is "basically" a .NET OCaml.
@tsujp Not really and tooling in F# has a different story it has been open for a while, as Isaac mentioned above in the thread vscode tooling for F# is actually decent. There's a core component (FSAC) that all of the major (VS, Rider, Ionide) and other (vim, emacs) players actually benefit from.
Here's the thing though the vscode tooling is mainly community driven in F#, are C# devs interested in the same kind of investment or they just turn the eye to Rider/VS or just wait for Microsoft to do something?
I'd say it is the last option as usual
My main puzzling question at this point is: Why has not the C# community take over ominsharp/forked it and continue its development to be a top notch open source solution after years of complaining and stalled development?
this issue comes out and suddenly omnisharp is very important and we should protect it over everything
Why has Microsoft have to do everything here?
The people who win/lose here IMO (in addition to Dustin's comments about how everything is made to keep you in the azure/windows loop) are very likely indie devs who are experimenting with C# they either get a sub-par experience with omnisharp and leave or get a very likely better experience with this new closed component, the rest of the C# community can simply wait (as they've been doing for most of the time) for Rider/VS to provide tooling
I think this is just another case of the unwillingness of the C# community to do something and just wait for Microsoft to do something and when Microsoft does something everybody just rages for the sake of raging, arguably this is backed by the fact that one would hardly ever want to compete vs Microsoft (thanks dotnet watch, appget, dnf, and others) but it also speaks volumes of the community around .NET unwilling to take leadership and unwilling to accept current leadership decisions
It's not only indie developers. I moved from Node.js to .NET because of C#, which is an excellent language. But I wouldn't have made the jump if it wasn't for the FOSS nature of .NET Core. Microsoft sold me the idea of true cross-platform .NET development with C#, and I loved it. Yet, the development experience on a non-Windows platform (Mac) is truly horrendous. VS for Mac is terrible (even the new 2022 version) and VSCode is simply not on-par with the "full" VS experience on Windows. So I had to go with Rider, and it was a major bummer because I thought .NET was really cross-platform in all of its aspects. But I thought "well, it's a new thing. For sure they'll improve over time and I'll be able to switch back to vscode in a couple of years"
Now they're trying to improve VSCode support but in a closed-source manner, and it feels like a betrayal of the original philosophy. C#/.NET is superior to JS/Node for development, IMHO. But it's much harder to justify in the broader web community if Microsoft makes these moves.
If it was me I would open source only the community components in Visual Studio itself, and the dotnet/winforms-designer repo if I truly fully embraced open source (since vscommunity is free I cant see why not open that part up but leave paid editions closed off).
I would also fully love if the LSP host was open sourced as well.
Besides VS uses dotnet/roslyn which is open source, and possibly a few other open source components by default.
I can understand if the VS codebase is either:
- too big of an repo right now due to files from microsoft/stl in it (and other things that can be split into multiple repos using submodules)
- in risk of being used like paint.net was for the whole renaming "to get free money" thing.
However it's a risk with all open source repos, not with just VS's closed repo. As such I would like it open source for the following reasons:
- It would Allow us to help review the codebases to improve them in areas where nobody found the issues before (find and squash problems before they become a real problem am I right?)
- It would Allow us to propose new features of our own that we might want in the IDE to help everyone.
- It would help people learn a few new things about Visual Studio, Possibly use it to dive in to learn theme extension elements not documented yet (the docs could have forgotten it with over 5k different color options).
- It would help the VS Team with people who want to contribute to VS in some way outside of Microsoft (ofc they would need some time to learn it's codebase).
- Could help drive faster updates to the IDE which in turn could get them released faster.
My main puzzling question at this point is: Why has not the C# community take over ominsharp/forked it and continue its development to be a top notch open source solution after years of complaining and stalled development?
The problem is that making an VSCode extension at this scope is hard, a new contributor has to figure out how everything works and it requires a experience with LSP, Roslyn, the debugger etc. Since .NET Core, C# is moving fast. Every year we get new language features, which requires changes.
I'm still using .NET Framework + WebForms at work which VSCode obvious doesn't support. For quick view changes, I don't want to open Rider so I've created https://github.com/GerardSmit/vscode-webforms. I know how difficult it is to figure out Roslyn and everything around it.
My main problem with all of this is that Microsoft wants to replace OmniSharp with their closed-source LSP server. Most of this could've been prevented if they said: hey, we're gonna make a new extension, which forks OmniSharp (and we'll contribute to OmniSharp the parts that are open-source) and rename the current one to "C# (Community)" instead of making it a setting in the options.
Because my understanding is that if you install the C# extension, it'll start the closed-source server (directly if you have a C# file open). This is like you installing Windows and Teams starts up, while you want to use Discord (oh... wait...)
Yet, the development experience on a non-Windows platform (Mac) is truly horrendous. VS for Mac is terrible (even the new 2022 version) and VSCode is simply not on-par with the "full" VS experience on Windows.
-- @dadepretto comment
Are there any blog posts or discussions where I can read more about this truly horrendous experience? Does the controversial .NET 6 Hot Reload work on Mac via VS 2022? I used to be a Mac user until I flooded my bedroom.
Yet, the development experience on a non-Windows platform (Mac) is truly horrendous. VS for Mac is terrible (even the new 2022 version) and VSCode is simply not on-par with the "full" VS experience on Windows.
-- @dadepretto commentAre there any blog posts or discussions where I can read more about this truly horrendous experience? Does the controversial .NET 6 Hot Reload work on Mac via VS 2022? I used to be a Mac user until I flooded my bedroom.
That depends on where it's used, if dotnet watch I think it does, if rider or VS for Mac I have not tried it on.
There is no great reason to do something good in the dark.
Just make it open source from the start
Respectfully, I want to add my feedback that keeping anything closed source is a terrible idea, and will only alienate the open source community that Microsoft has burned so many bridges attempting to entice before in the past. MS has an opportunity to truly live its publicly stated "One Microsoft" values here, and its failing, intentionally.
Yet, the development experience on a non-Windows platform (Mac) is truly horrendous. VS for Mac is terrible (even the new 2022 version) and VSCode is simply not on-par with the "full" VS experience on Windows.
-- @dadepretto commentAre there any blog posts or discussions where I can read more about this truly horrendous experience? Does the controversial .NET 6 Hot Reload work on Mac via VS 2022? I used to be a Mac user until I flooded my bedroom.
No blog posts, just my experience. But if you search I don’t think you’ll find anything good. VS for Mac should be discontinued in favor of true open support for C# in VSCode.
I agree, VS for Mac is hot garbage.
I agree, VS for Mac is hot garbage.
Agree, still surprised that they keep dragging that corpse around the block. That time would be better invested in vs code c# support.
I'm looking forward to these changes though. Omnisharp is great for what it is, but there is a lot of room for improvement.
closed source hurting a completely paid product like sublime
Why does it matter if Sublime Text is paid for, insert any IDE with plugin support. I just picked ST since it already supports OmniSharp, but we can more or less kiss that goodbye if this change goes ahead. Anyone who prefers ST wont be doing .NET work anymore.
-- @phillip-haydon comment
Because businesses do need to figure out how to make a profit. I do think, as I suggested, the long-term play here is code-as-a-service. In fact, I've been advocating for this paradigm shift since 2002! 😆
I don't think the head of DevDiv at Microsoft is the right leader to make that strategic transformation at Microsoft happen. That person started in VS Engineering and is far too loyal to a dead product to see where Microsoft / GitHub needs to be 10 years from now. If anything, VSCode is a black eye to DevDiv's inability to create new successful commercial products. Especially when Visual Studio Big Brother kept telling its users 32 bit Visual Studio was the best way to experience Visual Studio, and other ridiculous lame excuses for inferior engineering vs. basically every competitive product out there, and now Dart/Flutter dominating WPF/Silverlight/Blazor from an adoption standpoint.
So, even though people downvoted my post about Sublime Text and didn't like my messaging on it (since it's not overwhelmingly "open source everything!"), I do have a very concrete view in my mind of how I see Microsoft Visual Studio eventually dying, and what I think is DevDiv's best bet to have a product. Eventually incompetent leaders will get moved out of power, either through market share or layoff. In the mean time, Microsoft stack will fall behind by crappy LiveShare and non-cross platform Hot Reload functionality that is closed source and doesn't benefit from community bug fixes. That's on leadership way above Tim, unfortunately.
AWS XRay is a debug/tracing service, unsure what it has to do with any of the others you mentioned.
-- @phillip-haydon comment
That is definitely not AWS's end game for that product team. https://aws.amazon.com/products/developer-tools/ is just getting started. If DevDiv doesn't make changes, https://aws.amazon.com/amplify/ and Google Flutter will kick Microsoft to the curb in 10 years.
From a purely business perspective, it seems odd to restrict dev tools when you're making billions on Azure and PaaS. I'd think making the on-ramp to those things as easy and open as possible the optimal path.
But eventually, Microsoft will Microsoft I guess.
From a purely business perspective, it seems odd to restrict dev tools when you're making billions on Azure and PaaS. I'd think making the on-ramp to those things as easy and open as possible the optimal path.
That's the point. Tools have become a commodity. It started with LLVM crushing gcc and making pluggable compiler architecture infinitely easier than the preceding 40 years. Text editing is becoming a commodity too. The remaining value-add is bundling everything to Ship It 
in one service. That's what Enterprise customers would pay for.
From a purely business perspective, it seems odd to restrict dev tools when you're making billions on Azure and PaaS. I'd think making the on-ramp to those things as easy and open as possible the optimal path.
But eventually, Microsoft will Microsoft I guess.
The ideal .NET developer in Microsoft's eyes is writing code in Visual Studio on Windows and then hosting it on Azure.
This is in direct conflict of interest with what people want from an open platform, which .NET claims to be, and yet we have this as well as the dotnet watch fiasco (also no open debugger from Microsoft!).
Microsoft has shown willingness to compromise .NET's openness as an ecosystem to benefit themselves, and that's why people are angry.
Microsoft has shown willingness to compromise .NET's openness as an ecosystem to benefit themselves, and that's why people are angry.
Correction: I'm upset the head of DevDiv is sabotaging their best product in the last 15 years in order to maintain a dying feifdom (Visual Studio Big Brother) that probably won't be around in 10 years once Flutter whips its butt.
From a purely business perspective, it seems odd to restrict dev tools when you're making billions on Azure and PaaS. I'd think making the on-ramp to those things as easy and open as possible the optimal path.
But eventually, Microsoft will Microsoft I guess.
Never attribute to malice what is perfectly explainable by stupidity.
@timheuer Here are your real problems.
- You don't have a way to reproduce automated tests across platforms. This goes all the way to MSBuild having a funky start-up sequence that isn't documented anywhere and has no public automated regression tests. You cannot make a build in one step.
- Keeping Language Server Protocol open source means it will be taxing on VS Engineering to regression test open source contributions and plan major releases, as well as troubleshoot regressions in a paid-for product, so LSP can't be easily shared across free vscode and paid-for Visual Studio, because
- You can't regression test.
- VSCode has a lot better fault tolerance than Visual Studio, so bugs in the paid-for product actually have a much bigger impact than they due in VSCode due to VScode's multi-process client-server model. So, even if bugs are introduced in VScode, a lot of users simply don't notice it because it's fault tolerant. When the server dies, it jus spins right back up.
I believe that the tools necessary to develop .NET technologies should be fully open sourced, with no strings attached or carve outs like these.
These proprietary blobs only limit where, who and in which platforms .net can be used, and do not give the community the agency it deserves.
It Microsoft does not want to open source their technology, that is fine, but they should not hijack projects like OmniSharp and their users to push their next lock-in.
And if Microsoft does not want to release their debugger, that’s entirely their choice, but the .Net foundation should fund, embrace and promote alternative debuggers and an entire stack that is truly open, not this “open source with a leash” model that is emerging
Maybe I'm misreading it. But the only that will not be open source will be the "Host" to enable "extra features" and it will be the default but not the only option. I think it makes sense to have this "default" in exchange of active development and improvements in tooling, as long as it is not preventing others from extending the other components that are actually OSS.
On the other hand I totally agree with what @migueldeicaza says in his las paragraph.