csharp-language-server VS wcf

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.

https://github.com/dotnet/wcf/issues/4887

Technically speaking WCF is quite a bit more than SOAP, I think this might be a good overview of what people used it for (or maybe use it even now).

This article is wrong. It's hard to write and requires some out of the box thinking, but it's doable. You can see my implementation here. You can't easily implement cancellability though as you can't reset the state after an await as any changes you make will happen in a copy of the Execution Context. It could be done with a custom awaiter which chains a delegate to run before the await continuation so you can reset state on the callers ExecutionContext, but I didn't need that so didn't put the effort in.

MTOM on the client is now in code review in this Pull Request. After that's merged, I'll try to find time to port it to CoreWCF in the next month.

Next in my todo list is to add support for WCF, using CoreWCF. Long term, my goal is to also support GraphQL, SignalR, ODAta and WebSockets

There is another tool xscgen, that does not collapse container types and gets all the "inner types" correct but does not generate the Input/Output types or the client interface and client. dotnet-svcutil has another bug that prevents it from reusing external types.

There is a bug in dotnet-svcutil produces incorrect types and/or annotations when collapsing SOME pure container types into jagged arrays. dotnet-svcutil does not have the option to skip collapsing. During the contract implementation phase, which happens at runtime before the first request (ugh!), the code created viaRefEmit clashes with what the annotations specify and that exception is thrown.

I thought that wcf client exists for core? https://github.com/dotnet/wcf