You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
TLDR:
OmniSharp will run on .NET with all the latest performance and memory usage enhancements. It will load and work with .NET SDK projects as well as older .NET Framework projects (including Mono). If you have been using the .NET Framework builds, it will now be necessary to have the .NET Runtime installed either on its own or as part of the .NET SDK.
Background:
OmniSharp provides separate .NET Framework and .NET (-net6.0) builds of the language server. This is due to loading MSBuild in-process to perform design-time builds. A .NET Framework build is needed to load the .NET Framework MSBuild used by older .NET Framework projects (and Mono) and a .NET build is needed to load the .NET MSBuild used by SDK-style projects.
It is problematic having multiple builds of OmniSharp which requires new users to understand the differences between them and also to learn when each build should be used. An example of this is how the -net6.0 naming has become confusing as it is no longer the current .NET SDK release. Do users need .NET 6 SDK installed? Can users target .NET 8.0? etc..
The -net6.0 build of OmniSharp currently targets .NET 6.0. The process which is loading the .NET MSBuild has to be flexible as it has to load MSBuild from whichever SDK the user is targeting. This means it must target the lowest supported Framework. The language server misses out on a lot of performance enhancements due to this. For instance, OmniSharp is published with ReadyToRun enabled, however, this only provides a benefit when the .NET Runtime O# is running on is actually .NET 6.0. This likely hasn't been common for our users in several years.
Proposal:
Project loading should move out-of-process so that we will no longer need to load MSBuild into the language server process. This will allow a single OmniSharp build to load and provide language services to both older .NET Framework and .NET SDK projects. Since the language server is no longer restricted in which Framework we are targeting, we can target the latest and get all the performance benefits which come from it. Also, we can point new users to a single build and it will work for their mix of projects.
Breaking changes:
Any OmniSharp extension or installer that is expecting a -net6.0 build will fail.
Any OmniSharp extension or installer that is expecting the included Mono run script will fail.
Users of the .NET Framework build of OmniSharp will now need to install the .NET Runtime either on its own or as part of the .NET SDK.
The text was updated successfully, but these errors were encountered:
TLDR:
OmniSharp will run on .NET with all the latest performance and memory usage enhancements. It will load and work with .NET SDK projects as well as older .NET Framework projects (including Mono). If you have been using the .NET Framework builds, it will now be necessary to have the .NET Runtime installed either on its own or as part of the .NET SDK.
Background:
OmniSharp provides separate .NET Framework and .NET (
-net6.0
) builds of the language server. This is due to loading MSBuild in-process to perform design-time builds. A .NET Framework build is needed to load the .NET Framework MSBuild used by older .NET Framework projects (and Mono) and a .NET build is needed to load the .NET MSBuild used by SDK-style projects.It is problematic having multiple builds of OmniSharp which requires new users to understand the differences between them and also to learn when each build should be used. An example of this is how the
-net6.0
naming has become confusing as it is no longer the current .NET SDK release. Do users need .NET 6 SDK installed? Can users target .NET 8.0? etc..The
-net6.0
build of OmniSharp currently targets .NET 6.0. The process which is loading the .NET MSBuild has to be flexible as it has to load MSBuild from whichever SDK the user is targeting. This means it must target the lowest supported Framework. The language server misses out on a lot of performance enhancements due to this. For instance, OmniSharp is published with ReadyToRun enabled, however, this only provides a benefit when the .NET Runtime O# is running on is actually .NET 6.0. This likely hasn't been common for our users in several years.Proposal:
Project loading should move out-of-process so that we will no longer need to load MSBuild into the language server process. This will allow a single OmniSharp build to load and provide language services to both older .NET Framework and .NET SDK projects. Since the language server is no longer restricted in which Framework we are targeting, we can target the latest and get all the performance benefits which come from it. Also, we can point new users to a single build and it will work for their mix of projects.
Breaking changes:
-net6.0
build will fail.run
script will fail.The text was updated successfully, but these errors were encountered: