Plugin Architecture

[david-driscoll]

We need a solid way include plugins into OmniSharp.

The current example we have is Cake which requires only packages for OmniSharp.Abstractions and OmniSharp.Roslyn.

Things we need to do:

• [ ] Define our public surface area (Needs issue)
• [ ] Define what kind of plugins we support?
  • Diagnostics / Analyziers
  • Languages (cake, wyam?, vb?, f#?, config-r?)
  • New endpoints?
• [ ] Define how to load plugins (Needs issue)
  • Command Line args? (to deprecate)
  • Configuration System?
  • New request handler to load dynamically? Do we handle unloading? If we do what kind of crazy hell will this throw us into interms of AppDomains?
  • Custom configuration source that can be used to dynamically load new plugins?
• [ ] How to load plugins via extension in vscode? hidden command that is executed? cc @DustinCampbell
• [ ] How load plugins via extension in atom-ide? via services cc @daviwil
• [ ] How to load plugins via Eclipse / Eclipse Che? cc @mickaelistria @filipw

cc @mholo65

Original issue for reference:

208

[filipw]

Command Line args?

This is a left over from the past when we didn't have a good config-options story. IMHO this command line arg should be removed altogether and we should move plugin configuration to https://github.com/OmniSharp/omnisharp-roslyn/blob/master/src/OmniSharp.Abstractions/Options/OmniSharpOptions.cs

This way the entire configuration pipeline could be used for plugin set up (so command line args, json files, env variables). This would be both consistent with other config options, and flexible for users who can choose whatever option they want (including the possibility of globally configuring OmniSharp with plugins directory).

[david-driscoll]

Forgot about configuration, adding!

[bjorkstromm]

I think OmniSharp configuration pipeline is the way to go. Could plugin discovery be automated somehow? E.g. a VSCode extension that includes a plugin could register it somehow (search path which will the be appended to cmd line args for omnisharp.exe). User will have the possibility to override the search paths by adding a omnisharp.config in the workspace root.

[filipw]

Another issue will be to handle binding redirects. For the moment we do this https://github.com/OmniSharp/omnisharp-roslyn/blob/master/src/OmniSharp.Stdio/app.config#L8-L19 to facilitate third-party refactorings. It will likely need to grow. Plus, as a plugin author, you need to be aware that you may run against different Roslyn than you built for (which is really what happens in VS too).

[filipw]

A related issue: https://github.com/OmniSharp/omnisharp-roslyn/issues/773