Skip to content

Memo: Make OmniSharp greater

Jump to bottom Edit New page
Troy Dai edited this page Apr 22, 2016 · 2 revisions

Scenario Enhancement: Restore -> Build -> Test -> Debug (RBTD)

Restore

The restore scenario is supported today in OmniSharp. It is helpful to keep project's dependencies in sync. However the restore mechanism today is not ideal. The restores happen too frequent and often time restore same project repeatedly. It becomes even a worse issue to large project. The UI notifications become noisy in VS Code and the performance turns bad since restore causes network and disk operations.

  • Avoid duplicate restore. The work can be done together with Restore throttle after dotnet-projectmodel-server integration.
  • Restore throttle. The idea is to put restore request in a queue to slow down the operations. During the process duplicate requests can be combined and operation can be arranged in proper order based on it's dependency graph. Plus throttle to smooth the process.
  • Progress indicator - provide endpoint to indicate the restore process to enable progress UI represent in editor.
  • Dependency diagnostic information - for unresolved dependency, mismatch (both downgrade and upgrade) provide detailed structured diagnostic information to editor to enable readable editor error notification.

Build

The OmniSharp assist the build scenario through offer intellisense and refactorying. The OmniSharp doesn't participate in actual compilation or publishing. The users will do this either on command line or it up to individual editor to support.

It is not intuitive in lot of cases, since one of the most asked question I notice when developers begin using VS code is "so how do I build". To ask them to open a terminal is a let down.

If OmniSharp provide the endpoint for editors to get a the command line for building and publish a project, this will help editor plugin owner implement a in editor build experience easier.

Of course, to introduce the build and publish support in OmniSharp can be tricky. The compilation logic keeps envolving for project system like "dotnet-cli". If the OmniSharp is compiled with project systems, it will lack of the flexibility. So the plugin system needs to be refurbish to support out of process plugin.

Roslyn Analayzer is not utilized, either. It is an important feature to enrich the OmniSharp build scenarios.

  • Support out of command line / terminal build scenario - Dynamically generate build command to editor to launch correct build action.
  • Out of process plugin system (see Plugin System section)
  • Enhance the intellisense and code action by adding roslyn analyzer support.
  • Improve design time performance

Test

The test scenario is none exist. The best user can do is to rely on editor's task system to automatic the test. However if is often difficult to implement single test execution or test debugging.

The OmniSharp is in the better position to provide test information. For example, reflect the method current cursor is pointed at and return the test command with full qualilified name to the test. The editor cna in term execute the test case. In addition, the test result can be feedback so that editor can have UI representation on the test code for test results.

  • Support out of command line / terminal test scenario - provide test launch command dynamically to editor.
  • Support extensible test system provider.
  • Test results collection and marking

Debug

The coreclr-debugger integration works great in VS code, but it can get better with the OmniSharp.

For example, the OmniSharp can provide the concept of current project. With that inforamtion a even faster F5 scenario can be built without user intervention. The OmniSharp can provide information to update launch.json or directly edit the file.

  • Integrate with debugger, together with build and test enhancement support out of command line break into test and debug scenario.
  • Add endpoint to provider debugger launch information to editor.

Issues https://github.com/OmniSharp/omnisharp-vscode/issues/205

Engineering

There are a few things to do to improve the engineering experience

  • Agile and slimmer build
  • Fast build options
  • Stabilize CI
  • Better tests, decouple tests from common libraries and unskip tests
  • Better tests, cleaner test organization and better readability

Plugin system

  • Out of process plugins to support pure portable plugins.
  • Integrate dotnet-projectmodel-server with .NET project system, support side by side sdk and unify VS experience.
  • Portable ScriptCS plugin
Add a custom footer
Add a custom sidebar
Clone this wiki locally