Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
sim590 opened this issue Jun 12, 2021 · 8 comments
Open

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

sim590 opened this issue Jun 12, 2021 · 8 comments

Comments

@sim590
Copy link

sim590 commented Jun 12, 2021

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
Copy link
Member

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
Copy link
Member

filipw commented Jun 12, 2021

Can you share the repro project?

@sim590
Copy link
Author

sim590 commented Jun 12, 2021

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
Copy link
Author

sim590 commented Jun 14, 2021

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
Copy link
Member

@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
Copy link
Author

sim590 commented Jun 14, 2021

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
Copy link
Author

sim590 commented May 12, 2023

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

image

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
Copy link
Author

sim590 commented May 12, 2023

May be the following is more relevant:

image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants