vscode-csharp: Project fails to load, SDK 'Microsoft.NET.Sdk.Razor' not found

I know there are other issues with the same behavior but they mostly refer to MacOS and the fix seems to be to install an up to date Mono. The issue I am experiencing happens on Linux, with the latest version of Mono installed.

Environment data

dotnet --info output:

.NET Core SDK (reflecting any global.json):
 Version:   2.1.403
 Commit:    04e15494b6

Runtime Environment:
 OS Name:     debian
 OS Version:  
 OS Platform: Linux
 RID:         debian-x64
 Base Path:   /usr/share/dotnet/sdk/2.1.403/

Host (useful for support):
  Version: 2.1.5
  Commit:  290303f510

.NET Core SDKs installed:
  2.1.403 [/usr/share/dotnet/sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.All 2.1.5 [/usr/share/dotnet/shared/Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.5 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 2.1.5 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

VS Code version:

Version: 1.28.1
Commit: 3368db6750222d319c851f6d90eb619d886e08f5
Date: 2018-10-11T18:09:20.566Z
Electron: 2.0.9
Chrome: 61.0.3163.100
Node.js: 8.9.3
V8: 6.1.534.41
Architecture: x64

C# Extension version:

1.16.2

Mono version:

Mono JIT compiler version 5.16.0.179 (tarball Thu Oct  4 10:24:32 UTC 2018)
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 
	Interpreter:   yes
	LLVM:          yes(3.6.0svn-mono-/)
	GC:            sgen (concurrent by default)

Steps to reproduce

Just load any project with latest version on Linux. The exception is always the same:

Starting OmniSharp server at 10/12/2018, 10:02:57 AM
    Target: /home/fog/Customers/ventana/yes3/Yes.sln

OmniSharp server started with Mono 5.16.0.
    Path: /home/fog/.vscode/extensions/ms-vscode.csharp-1.16.2/.omnisharp/1.32.5/omnisharp/OmniSharp.exe
    PID: 9601

[info]: OmniSharp.Stdio.Host
        Starting OmniSharp on debian 0.0 (x64)
[info]: OmniSharp.Services.DotNetCliService
        DotNetPath set to dotnet
[info]: OmniSharp.MSBuild.Discovery.MSBuildLocator
        Located 2 MSBuild instance(s)
            1: Mono 15.0 - "/usr/lib/mono/msbuild/15.0/bin"
            2: StandAlone 15.0 - "/home/fog/.vscode/extensions/ms-vscode.csharp-1.16.2/.omnisharp/1.32.5/omnisharp/msbuild/15.0/Bin"
[info]: OmniSharp.MSBuild.Discovery.MSBuildLocator
        Registered MSBuild instance: Mono 15.0 - "/usr/lib/mono/msbuild/15.0/bin"
            CscToolPath = /home/fog/.vscode/extensions/ms-vscode.csharp-1.16.2/.omnisharp/1.32.5/omnisharp/msbuild/15.0/Bin/Roslyn
            CscToolExe = csc.exe
[info]: OmniSharp.Cake.CakeProjectSystem
        Detecting Cake files in '/home/fog/Customers/ventana/yes3'.
[info]: OmniSharp.Cake.CakeProjectSystem
        Could not find any Cake files
[info]: OmniSharp.WorkspaceInitializer
        Project system 'OmniSharp.DotNet.DotNetProjectSystem' is disabled in the configuration.
[info]: OmniSharp.MSBuild.ProjectSystem
        Detecting projects in '/home/fog/Customers/ventana/yes3/Yes.sln'.
[info]: OmniSharp.MSBuild.ProjectManager
        Queue project update for '/home/fog/Customers/ventana/yes3/backoffice/Backoffice.csproj'
[info]: OmniSharp.Script.ScriptProjectSystem
        Detecting CSX files in '/home/fog/Customers/ventana/yes3'.
[info]: OmniSharp.MSBuild.ProjectManager
        Loading project: /home/fog/Customers/ventana/yes3/backoffice/Backoffice.csproj
[info]: OmniSharp.Script.ScriptProjectSystem
        Could not find any CSX files
[info]: OmniSharp.WorkspaceInitializer
        Invoking Workspace Options Provider: OmniSharp.Roslyn.CSharp.Services.CSharpWorkspaceOptionsProvider
[info]: OmniSharp.WorkspaceInitializer
        Configuration finished.
[info]: OmniSharp.Stdio.Host
        Omnisharp server running using Stdio at location '/home/fog/Customers/ventana/yes3' on host 9448.
[warn]: OmniSharp.MSBuild.ProjectManager
        Failed to load project file '/home/fog/Customers/ventana/yes3/backoffice/Backoffice.csproj'.
/home/fog/Customers/ventana/yes3/backoffice/Backoffice.csproj(1,1)
Microsoft.Build.Exceptions.InvalidProjectFileException: The SDK 'Microsoft.NET.Sdk.Razor' specified could not be found.  /usr/lib/mono/msbuild/15.0/bin/Sdks/Microsoft.NET.Sdk.Web/Sdk/Sdk.props
  at Microsoft.Build.Shared.ProjectErrorUtilities.ThrowInvalidProject (System.String errorSubCategoryResourceName, Microsoft.Build.Shared.IElementLocation elementLocation, System.String resourceName, System.Object[] args) [0x00040] in <63bca7756d124ea392a81ca1b2d26b9c>:0 
  at Microsoft.Build.Shared.ProjectErrorUtilities.VerifyThrowInvalidProject[T1] (System.Boolean condition, System.String errorSubCategoryResourceName, Microsoft.Build.Shared.IElementLocation elementLocation, System.String resourceName, T1 arg0) [0x00003] in <63bca7756d124ea392a81ca1b2d26b9c>:0 
  at Microsoft.Build.Shared.ProjectErrorUtilities.ThrowInvalidProject[T1] (Microsoft.Build.Shared.IElementLocation elementLocation, System.String resourceName, T1 arg0) [0x00000] in <63bca7756d124ea392a81ca1b2d26b9c>:0 
  at Microsoft.Build.Evaluation.Evaluator`4[P,I,M,D].ExpandAndLoadImportsFromUnescapedImportExpressionConditioned (System.String directoryOfImportingFile, Microsoft.Build.Construction.ProjectImportElement importElement, System.Collections.Generic.List`1[Microsoft.Build.Construction.ProjectRootElement]& projects, Microsoft.Build.BackEnd.SdkResolution.SdkResult& sdkResult, System.Boolean throwOnFileNotExistsError) [0x0024e] in <63bca7756d124ea392a81ca1b2d26b9c>:0 
  at Microsoft.Build.Evaluation.Evaluator`4[P,I,M,D].ExpandAndLoadImports (System.String directoryOfImportingFile, Microsoft.Build.Construction.ProjectImportElement importElement, Microsoft.Build.BackEnd.SdkResolution.SdkResult& sdkResult) [0x00027] in <63bca7756d124ea392a81ca1b2d26b9c>:0 
  at Microsoft.Build.Evaluation.Evaluator`4[P,I,M,D].EvaluateImportElement (System.String directoryOfImportingFile, Microsoft.Build.Construction.ProjectImportElement importElement) [0x0000d] in <63bca7756d124ea392a81ca1b2d26b9c>:0 
  at Microsoft.Build.Evaluation.Evaluator`4[P,I,M,D].PerformDepthFirstPass (Microsoft.Build.Construction.ProjectRootElement currentProjectOrImport) [0x00209] in <63bca7756d124ea392a81ca1b2d26b9c>:0 
  at Microsoft.Build.Evaluation.Evaluator`4[P,I,M,D].EvaluateImportElement (System.String directoryOfImportingFile, Microsoft.Build.Construction.ProjectImportElement importElement) [0x00040] in <63bca7756d124ea392a81ca1b2d26b9c>:0 
  at Microsoft.Build.Evaluation.Evaluator`4[P,I,M,D].PerformDepthFirstPass (Microsoft.Build.Construction.ProjectRootElement currentProjectOrImport) [0x000e6] in <63bca7756d124ea392a81ca1b2d26b9c>:0 
  at Microsoft.Build.Evaluation.Evaluator`4[P,I,M,D].Evaluate (Microsoft.Build.BackEnd.Logging.ILoggingService loggingService, Microsoft.Build.Framework.BuildEventContext buildEventContext) [0x00103] in <63bca7756d124ea392a81ca1b2d26b9c>:0 
  at Microsoft.Build.Evaluation.Evaluator`4[P,I,M,D].Evaluate (Microsoft.Build.Evaluation.IEvaluatorData`4[P,I,M,D] data, Microsoft.Build.Construction.ProjectRootElement root, Microsoft.Build.Evaluation.ProjectLoadSettings loadSettings, System.Int32 maxNodeCount, Microsoft.Build.Collections.PropertyDictionary`1[T] environmentProperties, Microsoft.Build.BackEnd.Logging.ILoggingService loggingService, Microsoft.Build.Evaluation.IItemFactory`2[S,T] itemFactory, Microsoft.Build.Evaluation.IToolsetProvider toolsetProvider, Microsoft.Build.Evaluation.ProjectRootElementCache projectRootElementCache, Microsoft.Build.Framework.BuildEventContext buildEventContext, Microsoft.Build.Execution.ProjectInstance projectInstanceIfAnyForDebuggerOnly, Microsoft.Build.BackEnd.SdkResolution.ISdkResolverService sdkResolverService, System.Int32 submissionId, Microsoft.Build.Evaluation.Context.EvaluationContext evaluationContext) [0x0001a] in <63bca7756d124ea392a81ca1b2d26b9c>:0 
  at Microsoft.Build.Evaluation.Project.Reevaluate (Microsoft.Build.BackEnd.Logging.ILoggingService loggingServiceForEvaluation, Microsoft.Build.Evaluation.ProjectLoadSettings loadSettings) [0x0004c] in <63bca7756d124ea392a81ca1b2d26b9c>:0 
  at Microsoft.Build.Evaluation.Project.ReevaluateIfNecessary (Microsoft.Build.BackEnd.Logging.ILoggingService loggingServiceForEvaluation, Microsoft.Build.Evaluation.ProjectLoadSettings loadSettings) [0x00034] in <63bca7756d124ea392a81ca1b2d26b9c>:0 
  at Microsoft.Build.Evaluation.Project.ReevaluateIfNecessary (Microsoft.Build.BackEnd.Logging.ILoggingService loggingServiceForEvaluation) [0x00000] in <63bca7756d124ea392a81ca1b2d26b9c>:0 
  at Microsoft.Build.Evaluation.Project.ReevaluateIfNecessary (Microsoft.Build.Evaluation.Context.EvaluationContext evaluationContext) [0x00023] in <63bca7756d124ea392a81ca1b2d26b9c>:0 
  at Microsoft.Build.Evaluation.Project.Initialize (System.Collections.Generic.IDictionary`2[TKey,TValue] globalProperties, System.String toolsVersion, System.String subToolsetVersion, Microsoft.Build.Evaluation.ProjectLoadSettings loadSettings, Microsoft.Build.Evaluation.Context.EvaluationContext evaluationContext) [0x00126] in <63bca7756d124ea392a81ca1b2d26b9c>:0 
  at Microsoft.Build.Evaluation.Project..ctor (System.String projectFile, System.Collections.Generic.IDictionary`2[TKey,TValue] globalProperties, System.String toolsVersion, System.String subToolsetVersion, Microsoft.Build.Evaluation.ProjectCollection projectCollection, Microsoft.Build.Evaluation.ProjectLoadSettings loadSettings, Microsoft.Build.Evaluation.Context.EvaluationContext evaluationContext) [0x0009e] in <63bca7756d124ea392a81ca1b2d26b9c>:0 
  at Microsoft.Build.Evaluation.Project..ctor (System.String projectFile, System.Collections.Generic.IDictionary`2[TKey,TValue] globalProperties, System.String toolsVersion, System.String subToolsetVersion, Microsoft.Build.Evaluation.ProjectCollection projectCollection, Microsoft.Build.Evaluation.ProjectLoadSettings loadSettings) [0x00000] in <63bca7756d124ea392a81ca1b2d26b9c>:0 
  at Microsoft.Build.Evaluation.Project..ctor (System.String projectFile, System.Collections.Generic.IDictionary`2[TKey,TValue] globalProperties, System.String toolsVersion, Microsoft.Build.Evaluation.ProjectCollection projectCollection, Microsoft.Build.Evaluation.ProjectLoadSettings loadSettings) [0x00000] in <63bca7756d124ea392a81ca1b2d26b9c>:0 
  at Microsoft.Build.Evaluation.Project..ctor (System.String projectFile, System.Collections.Generic.IDictionary`2[TKey,TValue] globalProperties, System.String toolsVersion, Microsoft.Build.Evaluation.ProjectCollection projectCollection) [0x00000] in <63bca7756d124ea392a81ca1b2d26b9c>:0 
  at Microsoft.Build.Evaluation.ProjectCollection.LoadProject (System.String fileName, System.Collections.Generic.IDictionary`2[TKey,TValue] globalProperties, System.String toolsVersion) [0x000f7] in <63bca7756d124ea392a81ca1b2d26b9c>:0 
  at Microsoft.Build.Evaluation.ProjectCollection.LoadProject (System.String fileName, System.String toolsVersion) [0x00000] in <63bca7756d124ea392a81ca1b2d26b9c>:0 
  at OmniSharp.MSBuild.ProjectLoader.EvaluateProjectFileCore (System.String filePath) [0x0003e] in <99f3a3b619ce4010a7d6d489ffd5bcf1>:0 
  at OmniSharp.MSBuild.ProjectLoader.BuildProject (System.String filePath) [0x0000d] in <99f3a3b619ce4010a7d6d489ffd5bcf1>:0 
  at OmniSharp.MSBuild.ProjectFile.ProjectFileInfo.Load (System.String filePath, OmniSharp.MSBuild.ProjectLoader loader) [0x00015] in <99f3a3b619ce4010a7d6d489ffd5bcf1>:0 
  at OmniSharp.MSBuild.ProjectManager+<>c__DisplayClass25_0.<LoadProject>b__0 () [0x00000] in <99f3a3b619ce4010a7d6d489ffd5bcf1>:0 
  at (wrapper delegate-invoke) System.Func`1[System.ValueTuple`3[OmniSharp.MSBuild.ProjectFile.ProjectFileInfo,System.Collections.Immutable.ImmutableArray`1[OmniSharp.MSBuild.Logging.MSBuildDiagnostic],OmniSharp.MSBuild.Notification.ProjectLoadedEventArgs]].invoke_TResult()
  at OmniSharp.MSBuild.ProjectManager.LoadOrReloadProject (System.String projectFilePath, System.Func`1[TResult] loader) [0x0001b] in <99f3a3b619ce4010a7d6d489ffd5bcf1>:0 

[fail]: OmniSharp.MSBuild.ProjectManager
        Attemped to update project that is not loaded: /home/fog/Customers/ventana/yes3/backoffice/Backoffice.csproj

About this issue

Original URL
State: open
Created 6 years ago
Comments: 48 (3 by maintainers)

Most upvoted comments

I had a similar issue, but solved it. Try adding this to your PATH variable (.bashrc, .zshrc…):

MSBuildSDKsPath=/path/to/dotnet/sdk
# export MSBuildSDKsPath=/opt/dotnet/sdk/2.1.403/Sdks
# export PATH=$MSBuildSDKsPath:$PATH

I’m on Arch, so you’ll probably need to modify the path.

+28

arlomba on Oct 12, 2018

A better solution would be:

export MSBuildSDKsPath=/opt/dotnet/sdk/$(dotnet --version)/Sdks

This way you don’t have to update SDK’s version.

+24

arlomba on Oct 15, 2018

The problem is, that msbuild is also used by mono IDEs like MonoDevelop, So the previous path which is set to Mono SDKs (instead of dotnet SDKs) may be required by an IDE that compiles Mono code. I haven’t tried, But setting MSBuildSDKsPath may indeed conflict with mono IDEs.

I’ll check to see if it happens and update this comment asap. If it does, Perhaps a better way is to add the following in VS Code’s launch script :

For Ubuntu users : export MSBuildSDKsPath=/usr/share/dotnet/sdk/$(dotnet --version)/Sdks/

For Arch users : export MSBuildSDKsPath=/opt/dotnet/sdk/$(dotnet --version)/Sdks

UPDATE : I tested a simple console project using MonoDevelop 7 (FlatPack version though), and there was no problem. Since the issue is closed and continued on other places I’ll be watching them now.

DanteMarshal on Oct 17, 2018

There are a few things at play here. Let me give some background on how this is supposed to work. When MSBuild encounters <Project Sdk=...>, <Import Sdk=...> or <Sdk ...>, it calls into its SdkResolvers. These are plugins that live alongside MSBuild. One in particular, Microsoft.DotNet.MSBuildSdkResolver, resolves Sdks from the .NET Core SDK location based on dotnet being on PATH. There is also a default resolver that looks in MSBuildSdksPath. The default resolver is used if the plugin resolvers are not present or fail to find the Sdk in question. (* Technically, there is a priority given to each resolver and default resolver can go in between plugins, but the priorities aren’t assigned that way in practice.)

This error indicates that the default resolver was used to locate the Web SDK (because its Sdk.props is not in a .NET Core SDK location, but rather in the default MSBuildSdksPath), but then it failed to find the Razor SDK in the same default location:

Microsoft.Build.Exceptions.InvalidProjectFileException: The SDK 'Microsoft.NET.Sdk.Razor' specified could not be found.  /usr/lib/mono/msbuild/15.0/bin/Sdks/Microsoft.NET.Sdk.Web/Sdk/Sdk.props

So the first issue I see is that this mono msbuild is bundling Microsoft.NET.Sdk.Web without its Microsoft.NET.Sdk.Razor dependency. This means that the default sdk resolver will never be able to load web projects. Mono msbuild should bundle Microsoft.NET.Sdk.Razor if it is going to bundle Microsoft.NET.Sdk.Web in its default MSBuildSdksPath.

This default resolver would only be used if Microsoft.DotNet.MSBuildSdkResolver failed, which would happen in some normal circumstances:

The .NET Core SDK is not installed
The .NET Core SDK’s dotnet is not on the PATH
There is a global.json specifying a .NET Core SDK version that cannot be found.

From other hints above, these do not seem to apply here, but those are still the first things to check.

The next thing to verify is that the mono msbuild being used has Microsoft.DotNet.MSBuildSdkResolver in . /usr/lib/mono/msbuild/15.0/bin/SdkResolvers.

Finally, if it does, then there may be a bug in Microsoft.DotNet.MSBuildSdkResolver, which would fall on me. You can get the resolver to trace info to stderr by setting COREHOST_TRACE=1 as demonstrated at https://github.com/OmniSharp/omnisharp-vscode/issues/1849#issuecomment-343180388

cc @akoeplinger @radical

nguerrera on Oct 16, 2018

@Charly6596 actually the solution given by @anticide works: export MSBuildSDKsPath=/opt/dotnet/sdk/$(dotnet --version)/Sdks

But you have to persist that change for every new bash instance, therefore you can put that at the end of your .bashrc file along with what is needed for the local self-signed certificate (for proper https support in your local environment):

export MSBuildSDKsPath=/opt/dotnet/sdk/$(dotnet --version)/Sdks
export PATH="$PATH:/home/manjaro/.dotnet/tools"

I managed to have everything working with a Manjaro 18.02 Gnome edition on a live session. I had some other prior issues to that one: https://github.com/OmniSharp/omnisharp-vscode/issues/2837

Baby steps (similar to my other issue resolution in the link above)

Install yay to enjoy AUR without struggling with the command line: sudo pacman -Sy yay
Setup everything you need (aka the .NET Core SDK, Mono, MSBuild and Visual Studio Code Insiders): ~~yay -S dotnet-sdk mono binutils msbuild-stable visual-studio-code-insiders --noconfirm~~ yay -S dotnet-sdk mono binutils msbuild-stable visual-studio-code-bin --noconfirm (see my second post after that one below).
- Note: binutils cause the Gnome variant does not seem to embed that one natively, and this require for stripping in one of the steps of the msbuild-stable installation.
Add the required environment variables that you would like to export at the end of your .bashrc file in your home folder:
- export MSBuildSDKsPath=/opt/dotnet/sdk/$(dotnet --version)/Sdks
- export PATH="$PATH:/home/manjaro/.dotnet/tools"
Create a dummy project: dotnet new mvc
Start Visual Studio Code Insiders: code-insiders .
Install the C# extension <kbd>CTRL</kbd> + <kbd>SHIFT</kbd> + <kbd>P</kbd> ext install ms-vscode.csharp
Download the .NET Code Debugger for the C# extension (if needed / not already done the first time) <kbd>CTRL</kbd> + <kbd>SHIFT</kbd> + <kbd>P</kbd> Debug: Download .NET Core Debugger
Generate the launch.json and tasks.json files (if not already answered yes to the popup shows: “Would you like to add the required assets to build and debug your project?”) <kbd>CTRL</kbd> + <kbd>SHIFT</kbd> + <kbd>P</kbd> .NET: Generate Assets for Build and Debug
Install the tools for the development self-signed certificate dotnet tool install --global dotnet-dev-certs
Register the development self-signed certificate: dotnet dev-certs https
Debugging (.NET Core Launch (web)) <kbd>CTRL</kbd> + <kbd>SHIFT</kbd> + <kbd>D</kbd> <kbd>F5</kbd>

natalie-o-perret on Feb 11, 2019

I’m using Manjaro and setting MSBuildSDKsPath dit not solve the issue. What did solve the issue for me was copying ths Sdks folder to mono/msbuild/15.0/bin, in my case, cp -r /opt/dotnet/sdk/2.2.103/Sdks /usr/lib/mono/msbuild/15.0/bin After that, OmniSharp complained about the NugetFallbackFolder, which I created in /opt/dotnet/sdk. mkdir /opt/dotnet/sdk/NugetFallbackFolder Now OmniSharp doens’t complain about anything and I can build my projects appropriately.

flaviotsales on Jan 24, 2019

This started to happen to me on Windows 10!! I was able to solve also by setting the environment variable MSBuildSDKsPath to point to the latest sdks folder (in my case, C:\Program Files\dotnet\sdk\2.1.500\Sdks)

jsoques on Nov 27, 2018

Does not work anymore after the last update: https://aur.archlinux.org/packages/visual-studio-code-bin

natalie-o-perret on Feb 22, 2019

Setting MSBuildSDKsPath solved my problem on Fedora (vscode, .net core3 p3), but IMO a hint to set it should be added to .net core download page: https://dotnet.microsoft.com/download/thank-you/dotnet-sdk-3.0.100-preview3-linux-x64-binaries There are instructions to set PATH and DOTNET_ROOT but there is no advice to set MSBuildSDKsPath. So ultimately:

export DOTNET_ROOT=$HOME/dotnet
export PATH=$PATH:$DOTNET_ROOT
export MSBuildSDKsPath=$DOTNET_ROOT/sdk/$(dotnet --version)/Sdks

ptrwis on Mar 19, 2019

I’d like to get to the bottom of why folks are resorting to setting MSBuildSdksPath. See https://github.com/dotnet/cli/issues/10865. They end up breaking themselves with every SDK update. This should not be necessary as I’ve explained in https://github.com/OmniSharp/omnisharp-vscode/issues/2604#issuecomment-430330103.

EDIT: https://github.com/dotnet/cli/issues/10865 was on Windows so was probably set for a different reason, but I’m still curious about why folks are needing to set this on some Linux installations.

nguerrera on Feb 25, 2019

@Charly6596 glad to know that my solution could help you out

natalie-o-perret on Feb 6, 2019

I can confirm that setting MSBuildSDKsPath to the .NET Core sdks directory fixes the issue.

fogzot on Oct 15, 2018

I seem to be doing this wrong, still not very familiar with arch-based Linux (Antergos) yet, so basically I take this export string and paste it into the terminal and press enter and it should just work? export MSBuildSDKsPath=/opt/dotnet/sdk/$(dotnet --version)/Sdks

No, you do need to add that line to your .bash_profile file, then reload it with: source ~/.bash_profile

arlomba on Apr 24, 2019

Yes: RHEL 6.

There are three pieces in play: Microsoft.DotNet.MSBuildSdkResolver.dll (from msbuild.git), libhostfxr.so (from core-setup.git), and the rest of msbuild.git. The package dependency chain is msbuild ➡️ msbuild-libhostfxr ➡️ msbuild-sdkresolver

In the case of our RHEL/CentOS 6 repository, the msbuild-libhostfxr package is intentionally empty (because it cannot compile, because the available version of g++ is too old), and does not depend on msbuild-sdkresolver since it’s not functional without libhostfxr.so

I haven’t re-examined this mess since 2017, maybe things have changed since then to allow the relevant library to compile with RHEL 6’s neolithic g++. It’s using a git snapshot of core-setup from 2017-07-06.

directhex on Feb 25, 2019

@ehouarn-perret Thanks a lot, I fixed it with the following steps,

Uninstall mono, msbuild-stable and dotnet-sdk
yay -S dotnet-sdk mono msbuild-stable
Replace what i had in .bashrc related to dotnet, copy pasting this:

export MSBuildSDKsPath=/opt/dotnet/sdk/$(dotnet --version)/Sdks
export PATH="$PATH:/home/manjaro/.dotnet/tools"

I had export PATH="$PATH:$MSBuildSDKsPath"

Charly6596 on Feb 6, 2019

I had the same issue in Rider, I solve it configuring .Net binary as /opt/dotnet/dotnet. Configuring MSBuildSDKsPath didn’t help

trejjam on Dec 8, 2018

Another sad user of Manjaro having the same issue over here…

high-on-communism on Dec 3, 2018

This happens on my system too, I’m running Manjaro (Arch)

ThisDevDane on Nov 29, 2018

@nguerrera thank you for the explanation. @rchande I think the problem is that OmniSharp uses msbuild from the Mono distribution and Mono doesn’t include Microsoft.NET.Sdk.Razor. I don’t know why but when Mono msbuild is used, this part of the process doesn’t hold true:

One in particular, Microsoft.DotNet.MSBuildSdkResolver, resolves Sdks from the .NET Core SDK location based on dotnet being on PATH.

Because my .NET Core SDK dotnet executable is in path but gets completely ignored.

fogzot on Oct 19, 2018

@nguerrera great analysis! We are now tracking this issue on Mono side as well

marek-safar on Oct 17, 2018