Move OmniSharp to target net46 only

[DustinCampbell]

Fixes #666

Tagging @david-driscoll and @filipw specifically for a review since this is a significant change. It'd be great if anyone looking at this could build this branch and try it out.

This PR moves OmniSharp to target .NET Framework 4.6 exclusively and removes all of the netcoreapp1.1 builds. With this change, there are now only six flavors of OmniSharp that will be released:

• Windows builds that run on Desktop CLR.
  • omnisharp-win-x86.zip
  • omnisharp-win-x64.zip
• A *Nix build that be run on Mono 5.2.0 or greater. (Note that the --assembly-loader=strict flag must be specified when launch this build with Mono).
  • omnisharp-mono.tar.gz
• Standalone builds for OSX and Linux that include the Mono bits necessary to run OmniSharp.
  • omnisharp-osx.tar.gz
  • omnisharp-linux-x86.tar.gz
  • omnisharp-linux-x64.tar.gz

Important note This change does not affect the project types that OmniSharp supports. OmnISharp still supports .NET Core and .NET Framework, and Xamarin, Unity and other Mono-based projects.

For discussion: I chose to not include libuv.dll in the *Nix builds, but left them in the Windows builds. Allow me to explain my reasoning:

1. libuv.dll is used by Kestrel, and is only needed when using OmniSharp is an HTTP server. When using OmniSharp with stdio, it isn't necessary at all.
2. libuv.dll is a platform-specific native dependency. So, it wouldn't be possible to include it in the omnisharp-mono package anyway.
3. It is mind-numbingly easy to install on *Nix (e.g. brew install libuv or sudo apt-get install libuv1). It is not as easy to acquire on Windows however.

I'm open to discussion on this decision.

[bjorkstromm]

@DustinCampbell will you not support .NET Core in the future? Is it Full Framework or nothing?

[DustinCampbell]

@mholo65:

will you not support .NET Core in the future? Is it Full Framework or nothing?

There two aspects here:

1. What runtime OmniSharp itself runs on.
2. What sorts of projects OmniSharp can handle

This PR is only about the first point above. OmniSharp will no longer provide stand-alone builds that run on .NET Core. Primarily, this is because those builds are limited in what sorts of projects they can process. (i.e. MSBuild tasks targeting Full Framework will likely not run on CoreCLR). For OSX/Linux, we're going to be bundling a local Mono runtime so that OmniSharp will still run as a standalone application, without requiring Mono to be installed on the system (see #666 for details).

The second point above is not changing at all. OmniSharp will continue to support processing both .NET Core and Full Framework projects.

Does that answer your question?

[DustinCampbell]

Note that this will just be formalizing what we already do in C# for VS Code to run OmniSharp.

[bjorkstromm]

@DustinCampbell yes! Thanks, this is good news for us in Cake team, now we only need to target full framework for the Cake-plugin!

[DustinCampbell]

OK. Builds are passing. Tests are still somewhat problematic but they're working at the moment. Next up: packaging.

[DustinCampbell]

@david-driscoll & @filipw: I added you two in case you want to start looking at this or would like to try the branch out.

[DustinCampbell]

Note: This change does not move our libraries over to netstandard2.0. I think that's possibly the next thing, but it's not needed yet.

[filipw]

I'm all for it!

I'm very much eager to try this too.
For example it will help tackle some edge cases in scripting due to how we need to add references to runtime assemblies rather than (as you'd normally expect) to compile assemblies, which can be problematic when running OmniSharp on .NET Core.

[filipw]

We also have some conditional compilation directives which could be dropped now i.e. here or here

[DustinCampbell]

OK. I'm starting over a bit. I've rebased onto master with the new updates to the build.

[bjorkstromm]

@DustinCampbell any plans on updating target framework for OmniSharp.exe to net462 or net47? Or will this be done once netstandard2.0 is released? We are updating target frameworks for Cake in the next version and want to make sure Cake support (#932) still works as we need to load Cake.Core into OmniSharp in order to get the hostObjectType for scripting (https://github.com/OmniSharp/omnisharp-roslyn/pull/932/files#diff-3f2a987ebd93be29eeb71b6f6d923decR151)

[DustinCampbell]

No plans yet. Keeping the target framework it at 4.6 means that it will work on more Windows versions without the user needing to do anything.

[eamodio]

@DustinCampbell does this mean we won't be able to debug omnisharp on macOS/Linux (via vscode)?

[DustinCampbell]

I would expect the Mono Debugger extension to work, though I've never tried it.

[david-driscoll]

LGTM. Do we have a plan to handle new mono versions, some repo or script we can setup to manage that?

[DustinCampbell]

Do we have a plan to handle new mono versions, some repo or script we can setup to manage that?

Not yet. We're just using the bits that I regularly cobble together for C# for VS Code. I have a script that I use to copy the bits out of an installation of Mono on OSX. However, for Linux x86/x64, I have VMs where I sudo apt-get the latest mono and copy the runtimes out.

[DustinCampbell]

Are you guys OK if I merge this? It's a big change, so I want to be sure.

[filipw]

absolutely, I can't wait to get rid of .NET Core 😃🏆🍻

[DustinCampbell]

OK. Here it goes. 😄

[danmoseley]

@joperezr