Question: omnisharp-roslyn supports dotnet 2.0 preview in the latest release ?

[AndrienkoAleksandr]

Question: omnisharp-roslyn supports dotnet 2.0 preview in the latest release? I mean it will work if I have installed dotnet core 2 preview and generated project with help dotnet 2.0 preview?

[DustinCampbell]

Yes and no. It's not clear which builds it will work with. The mono build requires a mono fix in order to process .NET Core 2.0 preview projects. (We're using a special mono build with omnisharp-vscode for that).

[AndrienkoAleksandr]

So if I want to try mono roslyn binary I need to install mono and download roslyn mono binary?

[DustinCampbell]

In theory, yes. In practice, the fix hasn't made it's way into the latest Mono builds yet.

[AndrienkoAleksandr]

Ok. In the theory, should it work on Linux based os or it's should work only for Windows OS?

[DustinCampbell]

Windows builds work just fine.

[AndrienkoAleksandr]

Thanks :)

[DustinCampbell]

FWIW, it looks like that Mono fix I was referring to is in the latest Mono beta build: 5.2.0.196. However, it sounds like you were actually looking for Windows?

[AndrienkoAleksandr]

No, I am trying to use your binaries for Linux Fedora and Centos with installed dotnet 2.0 preview and with project generated with help dotnet 2 preview. And even more : all of this I launch in the docker container ...

[DustinCampbell]

If you're already trying it, should I assume it doesn't work? Are you getting some sort of error?

[AndrienkoAleksandr]

@DustinCampbell in the future releases you will be support dotnet-core binaries, or only net46 and mono binary?

[DustinCampbell]

In future release, OmniSharp will only have five releases:

• omnisharp-win-x64
• omnisharp-win-x86
• omnisharp-mono-osx
• omnisharp-linux-x86
• omnisharp-linux-x64

Mono builds will include a local Mono runtime and framework so you don't need to have Mono installed to make it work.

The releases will still support processing .NET Core, .NET Framework, Xamarin, Unity, etc. projects.

[AndrienkoAleksandr]

Can I get somehow mono local binary for using 1.22 binaries without installation mono? Or local mono is not ready yet or incompatible with current binaries?

[DustinCampbell]

You could try installing the latest C# for VS Code beta into VS Code. Then, open a C# project in VS Code, let it download the Mono runtime/framework and OmniSharp. Finally, grab the binaries from the extension folder, which should be something like ~/.vscode/extensions/ms-vscode/ms-vscode.csharp-1.12.0-beta4/bin. There'll be a run script in there that you can run to start OmniSharp.

Note that's not supported, but it should work until we've got proper OmniSharp builds with the Mono binaries included.

[omajid]

Hi. Sorry for jumping in late. I am trying to clarify my understanding of how omnisharp supports .NET Core.

Is it fair to say that Omnisharp-roslyn can work with just plain .NET Core? No mono required? I understand there may be reduced features (like it wont work against mono projects), but mono is not a hard dep if I just want to use omnisharp-roslyn against .NET Core?

Could you clarify the phrase "...The mono build requires a mono fix ..."? Is there a mono build of omnisharp and a non-mono build? Will the non-mono build just work on .NET Core? Any pointers to that build?

[DustinCampbell]

Let me clarify as there are two aspects to this problem:

1. What sorts of projects does OmniSharp support for processing, providing completion, etc.? This is not changing at all.
2. What does OmniSharp itself run on? This is changing, but it should be pretty much invisible to you.

Here are the details about the second point:

Yes, we'll be moving OmniSharp to run only on Mono. Sadly, due to the way that .NET Core handles assembly resolution, and the fact that MSBuild can run arbitrary code (in the form of Tasks) which can have additional dependencies, OmniSharp can't run on .NET Core and still handle all .NET Core projects. If we wanted to run on .NET Core, we'd need to (at worst) have a different build of OmniSharp matched to a particular .NET Core SDK. Does that make sense?

So, Mono will be a hard dependency, but OmniSharp will ship a local version of Mono that it runs on. So, you won't need to install Mono on the machine. This is how C# for VS Code works today.

[omajid]

First, thank you for explaining this!

Now, speaking with my Linux distro package maintainer hat on, please consider that this will make it harder for us to package and use omnisharp-roslyn.

What does OmniSharp itself run on? This is changing, but it should be pretty much invisible to you.

Unfortunately, dependencies and bundling local versions of packages are some of the bigger issues for Linux distributions. Many enterprise distributions do not ship mono but some have begun looking at .NET Core. Most distributions also want their software to be built from upstream source and prohibit local copies of binaries (so bundling mono would be a concern).

Yes, we'll be moving OmniSharp to run only on Mono. Sadly, due to the way that .NET Core handles assembly resolution, and the fact that MSBuild can run arbitrary code (in the form of Tasks) which can have additional dependencies, OmniSharp can't run on .NET Core and still handle all .NET Core projects.

What would it take to make .NET Core suitable for use by Omnisharp?

[david-driscoll]

The intent from our discussions at Summit were to ensure that the linux/osx packages listed under releases would include this built in mono, with a bootstrapping script (.sh file I assume). So for other editors, all you would have to do is pull the latest release and be able to integrate into your calling system fairly simply.

And dustin can correct me if I'm wrong, that the embedded mono will run on most environments self contained without any external dependencies. (I could be wrong here however)

[DustinCampbell]

Now, speaking with my Linux distro package maintainer hat on, please consider that this will make it harder for us to package and use omnisharp-roslyn.

Why is that? We are not adding a dependency on Mono to OmniSharp. We are including the Mono runtime and a set of framework binaries with OmniSharp, similar to how a standalone .NET Core app would work today.

What would it take to make .NET Core suitable for use by Omnisharp?

AFAICT, it is not possible without matching OmniSharp to the specific .NET Core SDK as the project you're trying to process.

[DustinCampbell]

And dustin can correct me if I'm wrong, that the embedded mono will run on most environments self contained without any external dependencies. (I could be wrong here however)

That's correct.

[omajid]

Why is that? We are not adding a dependency on Mono to OmniSharp. We are including the Mono runtime and a set of framework binaries with OmniSharp, similar to how a standalone .NET Core app would work today.

The way most linux distributions package software for inclusion is by unbundling all embedded binaries/libraries from a piece of software. Lets say you have a native application that displays pngs and uses libpng. There are potentially hundreds or thousands of applications in the linux distribution that will want to do that. So they rip the embedded copy of libpng out from all those applications and make them link against the one system-installed copy. This brings some very powerful advantages to the distribution:

• If a security vulnerability occurs in libpng, they can rebuild and ship one version of libpng and suddenly all applications that are using libpng are now fixed. The alternative would be to find every application that bundles libpng and fix it one at a time.
• If multiple versions of libpng were used in the distribution, the maintainers have to go find and fix every version of libpng that is being shipped. Imagine backporting a very sensitive security fix to a dozen different versions of libpng each requiring a slightly different fix.
• There is no chance that any project is carrying a forked version of libpng. Since all projects are using the same version, any and all performance improvements/bug fixes/security-fixes that go into upstream will eventually improve all users. If each project carried a fork of libpng with different local patches, upstream libpng will never benefit from it, and neither will other applications. Generally, this forces all applications using libpng to contribute their fixes/improvements upstream, improving open source software in general.

So, Linux distributions strongly prefer that any software they include (such as omnisharp-roslyn, in an ideal world) does not include bundled/embedded copies.

And yes, this problem will affect standalone .NET Core applications too. I fully expect Linux distributions to come up with guidelines saying .NET Core applications must be framework-dependent and use libraries on the system.

For more background, see:

• https://fedoraproject.org/wiki/Bundled_Libraries?rd=Packaging:Bundled_Libraries
• https://wiki.gentoo.org/wiki/Why_not_bundle_dependencies
• https://lwn.net/Articles/378865/

[DustinCampbell]

Ah. I see where you're coming from now. Sorry that I didn't catch on sooner.

FWIW, I don't think we have any aspirations of distributing OmniSharp in such a manner. As always, OmniSharp is simply distributed as a tarball/zip. I should also mention that OmniSharp can be run on a non-local Mono and we will likely provide a Mono package that isn't bundled with our Mono bits for any and all who wish to distribute it in such a fashion.

[sebbov]

Dustin/others.

I'm using the latest Mono beta on Linux with v1.22 but am still seeing issues. Is this expected at this time and if so, is there any work-around to make Omnisharp (specifically looking to make it work with Emacs) work with core 2.0 preview2?

Thanks,
-seb.

seb@sds1:/tmp/test$ cat /etc/os-release 
NAME="Ubuntu"
VERSION="16.04.2 LTS (Xenial Xerus)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 16.04.2 LTS"
VERSION_ID="16.04"
HOME_URL="http://www.ubuntu.com/"
SUPPORT_URL="http://help.ubuntu.com/"
BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/"
VERSION_CODENAME=xenial
UBUNTU_CODENAME=xenial

seb@sds1:/tmp/test$ mkdir omnisharp-roslyn
seb@sds1:/tmp/test$ wget -qO - https://github.com/OmniSharp/omnisharp-roslyn/releases/download/v1.22.0/omnisharp-ubuntu.16.04-x64-netcoreapp1.1.tar.gz | tar -C omnisharp-roslyn/ -xzf - 

seb@sds1:/tmp/test$ dotnet --version
2.0.0-preview2-006497
seb@sds1:/tmp/test$ dotnet new console -o app
The template "Console Application" was created successfully.

Processing post-creation actions...
Running 'dotnet restore' on app/app.csproj...
  Restoring packages for /tmp/test/app/app.csproj...
  Generating MSBuild file /tmp/test/app/obj/app.csproj.nuget.g.props.
  Generating MSBuild file /tmp/test/app/obj/app.csproj.nuget.g.targets.
  Restore completed in 234.92 ms for /tmp/test/app/app.csproj.


Restore succeeded.

seb@sds1:/tmp/test$ mono --version
Mono JIT compiler version 5.2.0.213 (tarball Thu Jul 27 14:33:05 UTC 2017)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
        TLS:           __thread
        SIGSEGV:       altstack
        Notifications: epoll
        Architecture:  amd64
        Disabled:      none
        Misc:          softdebug 
        LLVM:          supported, not enabled.
        GC:            sgen (concurrent by default)

seb@sds1:/tmp/test$ omnisharp-roslyn/OmniSharp -s $(pwd)/app/
OmniSharp: -s /tmp/test/app/
info: OmniSharp.Startup[0]
      Omnisharp server running on port '2000' at location '/tmp/test/app/' on host -1.
info: OmniSharp.DotNet.DotNetProjectSystem[0]
      Initializing in /tmp/test/app/
info: OmniSharp.DotNet.DotNetProjectSystem[0]
      Auto package restore: True
info: OmniSharp.DotNet.DotNetProjectSystem[0]
      Update workspace context
info: OmniSharp.DotNet.DotNetProjectSystem[0]
      Resolving projects references
info: OmniSharp.MSBuild.MSBuildProjectSystem[0]
      MSBUILD_EXE_PATH environment variable set to /tmp/test/omnisharp-roslyn/msbuild/MSBuild.dll
info: OmniSharp.MSBuild.MSBuildProjectSystem[0]
      MSBuildExtensionsPath environment variable set to /tmp/test/omnisharp-roslyn/msbuild
info: OmniSharp.MSBuild.MSBuildProjectSystem[0]
      MSBuild will use local OmniSharp installation.
info: OmniSharp.MSBuild.MSBuildProjectSystem[0]
      No solution files found in '/tmp/test/app/'
info: OmniSharp.MSBuild.MSBuildProjectSystem[0]
      Loading project: /tmp/test/app/app.csproj
fail: OmniSharp.MSBuild.ProjectFile.ProjectFileInfo[0]
      The "ReportAssetsLogMessages" task failed unexpectedly.
      System.IO.FileLoadException: Could not load file or assembly 'NuGet.ProjectModel, Version=4.3.0.3, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. Could not find or load a specific file. (Exception from HRESULT: 0x80131621)
      File name: 'NuGet.ProjectModel, Version=4.3.0.3, Culture=neutral, PublicKeyToken=31bf3856ad364e35'
         at Microsoft.NET.Build.Tasks.ReportAssetsLogMessages.ExecuteCore()
         at Microsoft.NET.Build.Tasks.TaskBase.Execute()
         at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
         at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__25.MoveNext()
fail: OmniSharp.MSBuild.ProjectFile.ProjectFileInfo[0]
      The "CheckForTargetInAssetsFile" task failed unexpectedly.
      System.IO.FileLoadException: Could not load file or assembly 'NuGet.ProjectModel, Version=4.3.0.3, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. Could not find or load a specific file. (Exception from HRESULT: 0x80131621)
      File name: 'NuGet.ProjectModel, Version=4.3.0.3, Culture=neutral, PublicKeyToken=31bf3856ad364e35'
         at Microsoft.NET.Build.Tasks.CheckForTargetInAssetsFile.ExecuteCore()
         at Microsoft.NET.Build.Tasks.TaskBase.Execute()
         at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
         at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__25.MoveNext()
warn: OmniSharp.MSBuild.MSBuildProjectSystem[0]
      Failed to load project file '/tmp/test/app/app.csproj'.
info: OmniSharp.Script.ScriptProjectSystem[0]
      Detecting CSX files in '/tmp/test/app/'.
info: OmniSharp.Script.ScriptProjectSystem[0]
      Could not find any CSX files
info: OmniSharp.Services.WorkspaceHelper[0]
      Invoking Workspace Options Provider: OmniSharp.Roslyn.CSharp.Services.CSharpWorkspaceOptionsProvider
info: OmniSharp.Startup[0]
      Configuration finished.

[DustinCampbell]

Update your OmniSharp script to pass --assembly-loader=strict to mono when launching OmniSharp. This change is already in but we haven't pushed a release with it yet.

[DustinCampbell]

@sebbov: Does that work for you now?

[sebbov]

@DustinCampbell yes it seems to, thanks!

I build from head of master and get:

seb@sds1:/tmp/omnisharp-roslyn$ artifacts/scripts/OmniSharp -s /tmp/test/app
OmniSharp: -s /tmp/test/app
info: OmniSharp.Startup[0]
      Omnisharp server running on port '2000' at location '/tmp/test/app' on host -1.
info: OmniSharp.DotNet.DotNetProjectSystem[0]
      Initializing in /tmp/test/app
info: OmniSharp.DotNet.DotNetProjectSystem[0]
      Auto package restore: True
info: OmniSharp.DotNet.DotNetProjectSystem[0]
      Update workspace context
info: OmniSharp.DotNet.DotNetProjectSystem[0]
      Resolving projects references
info: OmniSharp.MSBuild.MSBuildProjectSystem[0]
      OmniSharp initialized with Mono MSBuild.
          MSBUILD_EXE_PATH: /usr/lib/mono/msbuild/15.0/bin/MSBuild.dll
          MSBuildExtensionsPath: /usr/lib/mono/xbuild
          TargetFrameworkRootPath: /usr/lib/mono/xbuild-frameworks
          RoslynTargetsPath: /tmp/omnisharp-roslyn/artifacts/publish/OmniSharp/default/net46/msbuild/Roslyn
      
info: OmniSharp.MSBuild.MSBuildProjectSystem[0]
      No solution files found in '/tmp/test/app'
info: OmniSharp.MSBuild.MSBuildProjectSystem[0]
      Loading project: /tmp/test/app/app.csproj
info: OmniSharp.MSBuild.MSBuildProjectSystem[0]
      Update project: app
info: OmniSharp.Script.ScriptProjectSystem[0]
      Detecting CSX files in '/tmp/test/app'.
info: OmniSharp.Script.ScriptProjectSystem[0]
      Could not find any CSX files
info: OmniSharp.Services.WorkspaceHelper[0]
      Invoking Workspace Options Provider: OmniSharp.Roslyn.CSharp.Services.CSharpWorkspaceOptionsProvider
info: OmniSharp.Startup[0]
      Configuration finished.

The OmniSharp.Core script doesn't work, but I guess that may not be what I need after all.

[DustinCampbell]

Glad it works! OmniSharp.Core will ultimately be going away.

[DustinCampbell]

With #915 now merged, I think this can be closed.