Could not load file or assembly 'Microsoft.Build, Version=15.1.0.0'

[sim590]

As I have described here I'm having errors when trying to run omnisharp-roslyn on my project. Here is the log file:

omnisharp-roslyn.log

It has been 'anonymized'. I hope it is fine. Also, error messages are in french. I don't know how I can change them, sorry.

The project failing to load is configured for the .NET framework 4.8. When running, the following:

& "C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.8 Tools\gacutil.exe" /l Microsoft.Build.Framework

I am getting the following result:

Microsoft (R) .NET Global Assembly Cache Utility.  Version 4.0.30319.0
Copyright (c) Microsoft Corporation. Tous droits réservés.

Global Assembly Cache contient les assemblys suivants :
  Microsoft.Build.Framework, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL
  Microsoft.Build.Framework, Version=3.5.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL
  Microsoft.Build.Framework, Version=15.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL
  Microsoft.Build.Framework, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL

Nombre d'éléments = 4

The assembly should be there no? I may have also run:

& "C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.8 Tools\gacutil.exe" /i "C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\MSBuild\Current\Bin\Microsoft.Build.Framework.dll"

However, it did not change anything.

I ran the following inside the directory containing the csproj of the project I'm trying to open and got:

SDK .NET (refl?tant tous les fichiers global.json)?:
 Version:   5.0.301
 Commit:    ef17233f86

Environnement d'ex?cution?:
 OS Name:     Windows
 OS Version:  10.0.17763
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\5.0.301\

Host (useful for support):
  Version: 5.0.7
  Commit:  556582d964

.NET SDKs installed:
  2.1.524 [C:\Program Files\dotnet\sdk]
  3.1.300 [C:\Program Files\dotnet\sdk]
  3.1.410 [C:\Program Files\dotnet\sdk]
  5.0.301 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.All 2.1.18 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.1.28 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.18 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.1.28 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.1.4 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.1.16 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 5.0.7 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 2.1.18 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.28 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.1.4 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.1.16 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 5.0.7 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 3.1.4 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 3.1.16 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 5.0.7 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

To install additional .NET runtimes or SDKs:
  https://aka.ms/dotnet-download

I hope we can help me debug this.

Also

I have tried a few steps mentioned on my omnisharp-vim ticket.

I'm not sure if I'm on the right track or what I'm missing. I would really appreciate help on this.

[nickspoons]

A relevant detail I got from the OmniSharp log is that you appear to have Visual Studio 2019 installed, which I would have expected to take care of all msbuild requirements

[filipw]

Can you share the repro project?

[sim590]

A relevant detail I got from the OmniSharp log is that you appear to have Visual Studio 2019 installed, which I would have expected to take care of all msbuild requirements

Yes and I have no issue with building the project with Visual Studio 2019.

I must say that the project does have particular setup with some dlls found in some custom directories. Tell me if there's anything I can do to provide more information...

Can you share the repro project?

I'm sorry, I can't. Unfortunately, the project is proprietary.

[sim590]

I see that omnisharp lists places where it finds MSBuild DLLs:

[info]: OmniSharp.MSBuild.Discovery.MSBuildLocator
        Located 2 MSBuild instance(s)
            1: Visual Studio Professional 2019 16.6.30128.74 - "C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\MSBuild\Current\Bin"
            2: StandAlone 16.11.0 - "C:\Users\sdesaulniers\AppData\Local\omnisharp-vim\omnisharp-roslyn\.msbuild\Current\Bin"

Is it possible to give omnisharp a list of directory where it can look for DLLs ? I have a bunch of places where the file may be so if I could add directories for omnisharp to look for, then it could may be fix my issue?

[nickspoons]

@sim590 you'll get a lot more detail about what omnisharp-roslyn is doing, and where it's currently looking for DLLs, if you enable debug logging. Do this by passing the --loglevel debug flag to the server, or from omnisharp-vim with this setting:

let g:OmniSharp_loglevel = 'debug'

As for configuring DLL locations, the various omnisharp-roslyn configuration options are described in this wiki article: Configuration Options. However, as far as I know these options are for locating MSBuild and associated runtime/sdk DLLs, and not for project references. @filipw may be able to confirm whether this is correct.

[sim590]

I've searched for 15.1.0.0 in the following folder:

​C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\MSBuild

I put the results in this file: msbuild-15.1.0.0-references.txt

Is there something that comes out of the ordinary? May be I have some settings that omnisharp-roslyn picks up here while I wouldn't want it for compiling my project.

I got some info from my coworkers that we don't really use specifically Microsoft.Build.Framework 15.1.0.0. We shouldn't need it specifically from what I understand, so it seems like there's a setting that omnisharp-roslyn picks up and makes it use 15.1.0.0 for some reason, but I'm not sure what.

I have upgraded Visual Studio 2019 and I don't have it listing the assembly version 15.1.0.0 anymore:

Microsoft (R) .NET Global Assembly Cache Utility.  Version 4.0.30319.0
Copyright (c) Microsoft Corporation. Tous droits r?serv?s.

Global Assembly Cache contient les assemblys suivants?:
  Microsoft.Build.Framework, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL
  Microsoft.Build.Framework, Version=3.5.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL
  Microsoft.Build.Framework, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL

Nombre d'?l?ments = 3

I'm not sure if it's worth something to bring that up, but in any case.

[sim590]

I have found that Visual Studio config files have some relative paths for referencing Microsoft.Build DLLs:

I suspect that this does not play nice with Omnisharp or Omnisharp on WSL2. I currently use @nickspoons' suggestion for making Omnisharp-vim work under WSL2:

OmniSharp/omnisharp-vim#706 (comment)

@nickspoons: could the working directory be altered at some point for Omnisharp (or one of its subprocess) so that this could happen?

[sim590]

May be the following is more relevant:

[sim590]

I am trying to revive this issue.

Does omnisharp-roslyn actually support MSBuild custom tasks? I think that the issue seems to be related to this because the loading of Microsoft.Build actually fails whenever it tries to invoke the custom MSBuild tasks.

EDIT: I have just tried with VSCode and I'm getting the same error while Visual Studio doesn't have issue to build. On VSCode, I get:

[fail]: OmniSharp.MSBuild.ProjectLoader
        Unable to instantiate task "SomeCustomTaskThatWeWrote" from "C:\some\Custom\MSBuild\Task\That\We\Wrote.dll". Unable to load file or assembly 'Microsoft.Build, Version=15.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The specified file could not be found.

[JoeRobich]

Some background:

1. MSBuild assemblies are always built with the 15.1.0.0 AssemblyVersion for back compatibility reasons that I am not expert in. The AssemblyFileVersion will contain the true version of MSBuild.
2. OmniSharp loads the MSBuild from either a .NET SDK or an install of the MSBuild Tools. When running the -net6.0 builds of O# it will only look for MSBuild from SDKs. When running the .NET Framework build of O# it will load from MSBuild Tools installed on their own or installed with VS when using Windows, or from a mono-complete install if on MacOS or Linux.

Some thoughts:

1. O# does not load MSBuild tasks itself. It loads MSBuild and asks MSBuild to perform a build. If MSBuild is running the build, I am at a loss for why loading the Task causes it to not find MSBuild.
2. What is the benefit of the stdioproxy? Is it just to capture an omnisharp log?

Since this issue has been open for so long, it would be nice to have an updated O# log that includes the MSBuild discovery.

[sim590]

Here is the log:

omnisharp.log

It has been anonymized and I have removed some contents like when parts (or entirety) of a file was displayed in Buffer fields.

[nickspoons]

2. What is the benefit of the stdioproxy? Is it just to capture an omnisharp log?

I don't think stdioproxy is being used here, I can't see any references to it, except for in linked issues? But to answer the question:

There was an issue at one time where nvim on Windows could not communicate with .NET Framework projects, including O#-roslyn. We found that using a small .NET Core proxy program which intercepted and passed on all messages between neovim and O#-roslyn was a usable workaround. That turned out to be a neovim libuv bug and was eventually fixed in neovim in a much older version.

So actually stdioproxy doesn't do anything, simply allows neovim to talk to a .NET Core program instead of .NET Framework - there are obviously differences in the way the 2 frameworks handle stdio but that's above my pay grade.

[nickspoons]

@sim590 if I were you, I'd try to make a repro case. You can't share your project as it is so perhaps make a stripped down version that removes all code but keeps the project/solution/build tasks?

[sim590]

I'll try to do that.

[nickspoons]

Also, is this all only happening from WSL still? Can you run omnisharp-roslyn against your project from cmd.exe or windows terminal?

[sim590]

@nickspoons : No i have tried it on VSCode on Windows (see my first comment this year). Also, it is happening in Neovim running on Windows inside the Windows Terminal (no WSL). Both do the same error.

[sim590]

Can you run omnisharp-roslyn against your project from cmd.exe or windows terminal?

I ran from the terminal using the -v flag and I got the same error in json format.

Next, I'll try to reduce the whole thing to a reproducible short example.

[sim590]

OK, so I think that it turns out that I had to configure Platform and Configuration in my config file to make everything work properly (of course.........):

The following appeared in my log after I edited my config:

and now I don't have the issue anymore.

Talking about the config, I read the doc and I saw that there was the user global config and the per-project config. So, user config is located in the user directory, but what about the per-project directory? Let's say I have a repo that contains multiple subfolders that all contains separate MSBuild projects. Does omnisharp look for config file by backtracking up the directories until finds the first omnisharp.json file or does it just consider the omnisharp.json file that would be next to the csproj/sln file that is associated to the file being edited ? Because I'd like to have a config for the whole repo and not have to copy paste to all sub directories the config.

I tried putting the omnisharp.json file at the root of my repository, but it didn't have the same effect, therefore I think it doesn't consider it. What to do?

If it's not supported, please consider my comment as a feature request: look for the first omnisharp.json file by backtracking up in the directories structure to find the closest omnisharp.json to the project file. That's pretty much what Nuget does for Nuget.config, and MSBuild for Directory.*.props.

[sim590]

Also, it seems like VS Code cannot find %USERPROFILE%/.omnisharp/omnisharp.json while Neovim running under Pwsh in Windows Terminal does. How do I fix that?

I also tried the following without success:

• C:\Users\sdesaulniers\.vscode\extensions\ms-dotnettools.csharp-2.61.28-win32-x64\omnisharp.json
• C:\Users\sdesaulniers\.vscode\extensions\ms-dotnettools.csharp-2.61.28-win32-x64\.omnisharp\omnisharp.json
• C:\Users\sdesaulniers\.vscode\extensions\ms-dotnettools.csharp-2.61.28-win32-x64\.omnisharp\1.39.12\omnisharp.json
• C:\Users\sdesaulniers\AppData\Local\OmniSharp\omnisharp.json
• C:\Users\sdesaulniers\AppData\Roaming\OmniSharp\omnisharp.json

Not sure what's happening. Official wiki says %USERPROFILE%/.omnisharp/omnisharp.json, other issues have mentioned these paths that I tried above. None worked.

[sim590]

Actually, never mind. The issue is back. It had nothing to do with this.

I don't know why I couldn't see the errors anymore. I've been coding with the same instance of NeoVim for a good day and I didn't see the message in the log, but now it's back. Or, I mixed up something and I lost track of it.

But, since I my config is effective now in NeoVim, then Omnisharp seems to work for the most part. May be it's not gonna block me in the end.