Make OmniSharp-Roslyn portable.

[troydai]

I'd like start a conservation of making OmniSharp-Roslyn portable.

Pros:

• Avoid multiple versions of OmniSharp-Roslyn for different runtimes.
• Make the engineering process leaner.
• Gain addition platform support whenever dotnet expand it's supported platforms list.

Cons:

• Addition cli locating and acquiring logic.

[david-driscoll]

cc @DustinCampbell @hal-ler, I should dig up a list of other editor author's as well...

[david-driscoll]

We need to think about the problem domain. That problem domain is at it's core "editor intelligence", so our consumers are not developers, but instead editors that we're making smarter.

So I like having a native executable, for editor author's the process to obtain OmniSharp is fairly straight forward. Download, Extract, Run. You don't have to worry about the runtime, you can have everything so that consumers can start working immediately.

There are challenges, we need a way to stay in sync with the supported os graph of CoreClr. I'm sure we can automate this, or simplify it greatly.

I'm not saying we shouldn't have a portable version, we should definitely have one that is portable. It's just obtaining the portable version would painful, and involve a ton of rework for each and every editor to manage.

The flow would be something like Download, Extract, Determine Runtime, Check Runtime, Download Runtime (if needed), Run. That is a ton of work, work that generally each editor has to do on it's own.

It's possible to script out that work, but now we're back in the place of managing fetch script for sh and bat/ps1. And also potentially doing things the editor doesn't want us to do (where we drop OmniSharp versions and so on).

It might be more work for OmniSharp itself, to have to build all the artifacts and have them ready. On the other hand the amount of effort on the Editor side is greatly simplified. It also shields the Editor Authors from the constant churn that's happening on the cli side, they don't have to know what a portable runtime is if they don't want to.

[hal-ler]

What is the status of using portable apps with dotnet test? That would at least get rid of a lot of unnecessary maintenance. Having to only update a single project.json and build.cake with new runtimes (maybe even finding a way to synchronize the two) seems plausible.

[hal-ler]

Is there a way to have some aliases in the project.json for the different frameworks, which the build script could parse to populate it's list automatically?

Like "Ubuntu.14.04-x64":"travis-linux-1".

[hal-ler]

Is my understanding correct that there is a single "runnable" TFM right now, meaning that shared platform and standalone builds are exclusive?

[DustinCampbell]

This will be happening with #666.