Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
3 of 4 tasks
timheuer opened this issue Jun 15, 2022 · 323 comments
Open
3 of 4 tasks

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

timheuer opened this issue Jun 15, 2022 · 323 comments

Comments

@timheuer
Copy link
Collaborator

timheuer commented Jun 15, 2022

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.

@JoeRobich JoeRobich pinned this issue Jun 15, 2022
@GerardSmit
Copy link

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.

@mhmd-azeez
Copy link

mhmd-azeez commented Jun 15, 2022

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
Copy link

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
Copy link

nyeogmi commented Jun 15, 2022

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
Copy link

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
Copy link

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
Copy link

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
Copy link
Contributor

ssg commented Jun 15, 2022

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
Copy link

PJB3005 commented Jun 15, 2022

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
Copy link

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
Copy link
Contributor

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
Copy link

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

@voronoipotato
Copy link

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
Copy link

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
Copy link
Contributor

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
Copy link
Contributor

david-driscoll commented Jun 15, 2022

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.

image

@glennawatson
Copy link

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
Copy link

sumitkm commented Jun 15, 2022

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
Copy link

isaacabraham commented Jun 15, 2022

@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
Copy link

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
Copy link

dustinmoris commented Jun 15, 2022

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
Copy link

rgwood commented Jun 16, 2022

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
Copy link

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
Copy link
Member

ghuntley commented Jun 16, 2022

🆕 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

screencapture-isdotnetopen-2022-06-16-10_36_49

See also dotnet/core#505

@timheuer
Copy link
Collaborator Author

timheuer commented Jun 16, 2022

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
Copy link

ghost commented Jun 16, 2022

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
Copy link

voronoipotato commented Jun 16, 2022

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

@grandslammer
Copy link

grandslammer commented May 31, 2023

I recently started using VS Code for writing C# code and the "ms-dotnettools.csharp" formatter is completely broken. I've tried everything to get it to work including checking for any potential conflicts (with Prettier etc), spaces indentation detection, and more.

I have had similar formatting issues with other languages too but have always managed to fix them via adding language-specific rules to settings.json. But that doesn't work with C# for some reason.

For example, the demo WeatherForecastController file that's generated whenever a web API project is scaffolded looks like this out of the box:
image

And here is the same after I format on save:
image

The red spaces on the left are from the indent-rainbow extension. It shows red when it detects an indentation error. It should display as a light yellow.
Also note the braces not being indented properly upon formatting, with the opening brace being indented by 2 spaces and the closing brace indented by 4.

I really hope these formatting issues get addressed in future!

UPDATE:
I eventually found a temporary solution by a omnisharp.json file in the project root with the following contents:

{
  "FormattingOptions": {
    "UseTabs": false,
    "TabSize": 4,
    "IndentationSize": 4
  }
}

However, this has to be done for every project and there does not seem to be a way to configure this globally for VS Code.

@NCLnclNCL
Copy link

Out of all the languages that VSCode supports, C# ironically has the worst support out of any of them. Even C++ with clangd works better. I've been patiently waiting years hoping that things would improve instead of moving to Rider because I use VSCode with so many other languages and frameworks. I'm losing faith that things will ever improve in my lifetime.

I was very happy to see this announcement 1 year ago, but once again disappointed that there hasn't been any updates whatsoever since then.

No bro, i can code in vscode is good

@XorZy
Copy link

XorZy commented Jun 1, 2023

I really hope these formatting issues get addressed in future!

I would not hold my breath.
It has become apparent MS does not want people to migrate from Visual Studio to VS Code.
This extension is on life support and the promised “LSP Tools Host” is just vaporware to precipitate its death.
What a shame, C# is such a nice language but I have to wonder how many people were turned off by this broken extension.
Imagine being a new C# dev and having your code destroyed by the formatter, spending hours trying to fix imaginary errors, and having to restart the extension about 20 times per day.
I know I would have given up trying to learn C# if Omnisharp existed back then.
This will hurt C# in the long run but MS does not seem to care 🤷

@Chizaruu
Copy link

Chizaruu commented Jun 5, 2023

I recently started using VS Code for writing C# code and the "ms-dotnettools.csharp" formatter is completely broken. I've tried everything to get it to work including checking for any potential conflicts (with Prettier etc), spaces indentation detection, and more.

I have had similar formatting issues with other languages too but have always managed to fix them via adding language-specific rules to settings.json. But that doesn't work with C# for some reason.

For example, the demo WeatherForecastController file that's generated whenever a web API project is scaffolded looks like this out of the box: image

And here is the same after I format on save: image

The red spaces on the left are from the indent-rainbow extension. It shows red when it detects an indentation error. It should display as a light yellow. Also note the braces not being indented properly upon formatting, with the opening brace being indented by 2 spaces and the closing brace indented by 4.

I really hope these formatting issues get addressed in future!

UPDATE: I eventually found a temporary solution by a omnisharp.json file in the project root with the following contents:

{
  "FormattingOptions": {
    "UseTabs": false,
    "TabSize": 4,
    "IndentationSize": 4
  }
}

However, this has to be done for every project and there does not seem to be a way to configure this globally for VS Code.

Could you not just modify the global json file? o-o
%USERPROFILE%/.omnisharp

@webczat
Copy link

webczat commented Jun 5, 2023

You can just... use editorconfig to set any formatter options, instead of vs options. if you have vs with non standard options or defaults differ, you can make vs generate an editorconfig. both vsc and vs respect it for projects containing it.

@alexdreptu
Copy link

@Chizaruu try CSharpier, it works great. I've been using it for some time.

@Meligy
Copy link

Meligy commented Jun 6, 2023

In terms of format tooling, I hate that Csharpier is not compatible with standard dotnet format and the formatting options in .editorconfig, but that's probably beyond Omnisharp itself. I don't think the issue reported in Chizaruu's comment is common as I haven't seen it in many C# projects.

And that's not to say that Omnisharp based formatting is enough, even with .editorconfig, it's lacking a lot, especially for LINQ queries and fluent/chained method calls.

@webczat
Copy link

webczat commented Jun 6, 2023

pretty sure omnisharp based formatting is same as vs. note that it's not omnisharp formatting, it's roslyn itself.

@Meligy
Copy link

Meligy commented Jun 6, 2023

pretty sure omnisharp based formatting is same as vs. note that it's not omnisharp formatting, it's roslyn itself.

You are right that Onnisharp formatting is Roslyn really. But I think VS has more formatting capabilities than just Roslyn.

@webczat
Copy link

webczat commented Jun 6, 2023

Interestingly, it doesn't, from what I know of.

@NCLnclNCL
Copy link

pretty sure omnisharp based formatting is same as vs. note that it's not omnisharp formatting, it's roslyn itself.

You are right that Onnisharp formatting is Roslyn really. But I think VS has more formatting capabilities than just Roslyn.

Omnisharp too bad for c# in vscode

@Igorgro
Copy link

Igorgro commented Jun 6, 2023

According to #5705

This extension is being updated to be powered by a new fully open-source Language Server Protocol (LSP) Host

the new language server will be fully open-source 🎉

@Igorgro
Copy link

Igorgro commented Jun 6, 2023

The only problem is that new C# extensions https://marketplace.visualstudio.com/items?itemName=ms-dotnettools.csharp and https://marketplace.visualstudio.com/items?itemName=ms-dotnettools.csdevkit are not open-source (at least for now)

@timheuer timheuer unpinned this issue Jun 6, 2023
@MichalPetryka
Copy link

MichalPetryka commented Jun 6, 2023

The only problem is that new C# extensions https://marketplace.visualstudio.com/items?itemName=ms-dotnettools.csharp and https://marketplace.visualstudio.com/items?itemName=ms-dotnettools.csdevkit are not open-source (at least for now)

And won't be for the devkit.

@exyi
Copy link

exyi commented Jun 6, 2023

The new official announcement is here: #5708

I don't think they lie about is being open, but I can't find the source code of the new "LSP Host" either. If anyone knows, posting here a link would be appreciated.

@Igorgro
Copy link

Igorgro commented Jun 6, 2023

I think it should be either a part of new extension codebase or the Roslyn itself. I think we should wait for the nex anouncement in June 13

@timheuer
Copy link
Collaborator Author

timheuer commented Jun 6, 2023

Hi all, please see an update here: #5708 -- FYI the repo is in the process of being moved this week and requires a bit of coordination we didn't align just quite in time today. Please know we're working on migrating the source to the repo identified in this update.

@Meligy
Copy link

Meligy commented Jun 6, 2023

Thanks a lot for the great work. It's also amazing to see the C# Dev Kit announcement mentioning debugging, another key area that could use some love.

I have a question if you may. Is IntellliCode supposed to work side by side with GitHub Copilot? In the past they seemed to do pretty much the same thing, so I kept only Copilot, but this seems different in the context of C# development.

Update

I moved my question to the new thread.

@timheuer
Copy link
Collaborator Author

timheuer commented Jun 7, 2023

The only problem is that new C# extensions marketplace.visualstudio.com/items?itemName=ms-dotnettools.csharp

Just a correction -- the ms-dotnettools.csharp one is this repo and that is the OSS one.

@timheuer
Copy link
Collaborator Author

timheuer commented Jun 7, 2023

The new official announcement is here: #5708

I don't think they lie about is being open, but I can't find the source code of the new "LSP Host" either. If anyone knows, posting here a link would be appreciated.

This is the repo where it will be at -- we are in the process of moving the code from internal repo to here...might take us a week to ensure we have the infrastructure moved for build/release.

@Chizaruu
Copy link

Chizaruu commented Jun 7, 2023

Cool beans

@jasonmalinowski
Copy link
Member

I don't think they lie about is being open, but I can't find the source code of the new "LSP Host" either. If anyone knows, posting here a link would be appreciated.

@exyi: The LSP server itself is being made public in dotnet/roslyn#68461 and should merge into Roslyn in a day or so once some other internal infrastructure gets working. The changes in this repo to launch that LSP server we should get posted in a day or two.

@lawrence-laz
Copy link

A couple of questions about the new changes in regards to other editors (ex. nvim):

  1. Will the new LSP host be available for use with external editors? Are there any licensing issues in using it outside of VSCode?
  2. There were some mentions about improved debugging experience. Will this by any chance mean that debugger will be available for non VSCode editors as well?

@CyrusNajmabadi
Copy link
Member

CyrusNajmabadi commented Jun 8, 2023

Will the new LSP host be available for use with external editors? Are there any licensing issues in using it outside of VSCode?

The LSP host is something roslyn is building, and is intended to be licensed the same way roslyn is licensed. We have a couple of minor snafus in the licensing being totally correct there, but we should be able to get through all of that in the short term. This code will be just a normal library/exe that you can use based on the roslyn license. :)

From the Roslyn perspective, we want this to be a high quality, scalable, efficient, compliant impl of the LSP protocol on top of C#. Our hope is that people find value and use for this in whatever domains they'd like it for :)

There were some mentions about improved debugging experience. Will this by any chance mean that debugger will be available for non VSCode editors as well?

There's been no change around the debugger licensing currently. Sorry!

@CyrusNajmabadi
Copy link
Member

Note: you can see the server here: https://github.com/dotnet/roslyn/blob/main/src/Features/LanguageServer/Microsoft.CodeAnalysis.LanguageServer/Program.cs ! :)

As per above, this is all part of our Roslyn OSS story, and delivering a high quality LSP server impl deliverable as is a core part of that story we are committed to. If you run into issues with this server, def let us know as we expect some small growing pains as this is adopted broadly, and we want to fix those problems quickly :)

@boost1231
Copy link

There's been no change around the debugger licensing currently. Sorry!

Is there a reason the Debugger can't be made to use in any editor given you have a paid subscription to say Visual Studio Professional?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests