try-convert VS csharp-language-server

dotnet upgrade assistant or dotnet try-convert can help with that.

- dotnet try-convert: https://github.com/dotnet/try-convert

try-convert

Check out https://github.com/dotnet/try-convert

https://github.com/dotnet/try-convert (usually) makes this a breeze.

I'm looking to move one of our software suites from .NET Framework 4.7 to .NET 6. A lot of online guides recommend starting with the Microsoft conversion tools to ease/speed up the process. There seem to be two tools that are used for it try-convert and upgrade-assistant. However, I'm not sure I understand the difference between them and when should I use which tool (assuming that it matters).

That would mean you have pretty simple code then, relatively speaking. I helped write the underlying project conversion tool used in the Migration Assistant and found that there's a lot of big and incompatible differences well before you even get into which APIs you're using. Lots of enterprise apps end up using them, whether or not the authors of those apps are aware of it.

migrate to SDK-style project files - try-convert does wonders here

Are you using .NET SDK-style projects, or the old scary ones? The latter should load, but since you can't even create them anymore I would expect them to bit rot over time. The try-convert tool should be able to help with that (I wrote most of it, plus the F# support!)

there's https://github.com/dotnet/try-convert. Haven't tried it; I instead use https://github.com/hvanbakel/CsprojToVs2017, but I assume the former might be a better choice by now.

The recommended approach used to be coc-omnisharp, but it has been discontinued in favor of chsarp-ls. I have installed csharp-ls with dotnet tool install --global csharp-ls, and the executable is on ~/.dotnet/tools. The following is on my coc settings:

I switched to https://github.com/razzmatazz/csharp-language-server which doesn't have as many features.

Apropos lsp, these two might be interesting, if you haven't yet given up on C#. Again, that should work on many editors, including the evil one at hand. Note how both explicitly name vim, emacs and vscode in their documentation.

It using lsp protol.i tried the new version of omnisharp with lsp but its really bad, 2 client extension if you don't want to use omnisharp https://github.com/statiolake/vscode-csharp-ls And https://github.com/vytautassurvila/vscode-csharp-ls And last, server lsp https://github.com/razzmatazz/csharp-language-server

lol quite specific. do you know https://github.com/razzmatazz/csharp-language-server ?

There's Saulius's lsp too too, altogh I haven't tried it yet.

You could also set the semantic tokens capability to nil. Another alternative to omnisharp is csharp-language-server which has recently added support for semantic tokens.

I ended up using csharp_ls, https://github.com/razzmatazz/csharp-language-server/issues/34 posted what I found here. Once I got things pointing to the right mono dll it started working great.

Sadly, OmniSharp (the LSP for vscode and nvim) isn't all that great. The performance is incredibly bad, easily orders of magnitude worse than VS and Rider.

There is this alternative LSP, which I plan to try out still: https://github.com/razzmatazz/csharp-language-server

I don't know about your case, but wanted to add a comment. I had some problems recently with omnisharp, and someone recommended me to try https://github.com/razzmatazz/csharp-language-server instead of omnisharp, I switched and so far with no issues.