In a solution I'm working on, I have a WPF project which references a library project. Both are currently targeting netcoreapp5.0 which works fine. If I change both to target net5.0 (the preferred TFM going forward), I get this error from OmniSharp:
Project '..\core\core.csproj' targets 'net5.0'. It cannot be referenced by a project that targets '.NETCoreApp,Version=v5.0'.
(Fwiw, I made absolutely sure there are no projects still using netcoreapp5.0 in the solution.)
OmniSharp will use msbuild from Visual Studio 2019 if it's found on your machine. is your VS2019 updated to handle net5.0 (so to VS 16.5+)?
I have VS 2019 16.5.4 installed (according to Visual Studio Installer).
OmniSharp seems to be picking it up properly:
[info]: OmniSharp.MSBuild.Discovery.MSBuildLocator
Located 2 MSBuild instance(s)
1: Visual Studio Community 2019 16.5.30011.22 - "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin"
2: StandAlone 16.4 - "C:\Users\alex\.vscode\extensions\ms-dotnettools.csharp-1.21.18\.omnisharp\1.35.1\.msbuild\Current\Bin"
[info]: OmniSharp.MSBuild.Discovery.MSBuildLocator
Registered MSBuild instance: Visual Studio Community 2019 16.5.30011.22 - "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin"
then everything should work - can you post the full log at debug level?
Mmh, ordinarily I would, but there's thousands of lines of output and this is a private project, so I probably can't just post it as-is. Is there a particular subset of the log I should grab?
By the way, I noticed that dotnet msbuild -version says:
Microsoft (R) Build Engine version 16.6.0-preview-20181-02+9f3e4e725 for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.
16.6.0.18102
Meanwhile msbuild -version in the VS 2019 developer command prompt says:
Microsoft (R) Build Engine version 16.5.0+d4cbfca49 for .NET Framework
Copyright (C) Microsoft Corporation. All rights reserved.
16.5.0.12403
I don't know if that would make any difference, but it seems worth noting since dotnet CLI has no problem with either netcoreapp5.0 or net5.0 while OmniSharp only accepts netcoreapp5.0.
you will have to provide a small repro of this and a log because otherwise it's unfortunately impossible to troubleshoot.
net5.0 should definitely be supported, we explicitly have a test that verifies net5.0 TFM as part of the CI build https://github.com/OmniSharp/omnisharp-roslyn/blob/v1.35.1/test-assets/test-projects/Net50Project/net50-lib/net50-lib.csproj#L4
mkdir test && cd test
dotnet new classlib -n lib -f net5.0
dotnet new wpf -n wpf
sed -i 's/netcoreapp5.0/net5.0/' wpf/wpf.csproj
dotnet add wpf reference lib
dotnet new sln
dotnet sln add lib
dotnet sln add wpf
dotnet build # Will work fine.
Then open the folder in VS Code and you'll get the error I mentioned from OmniSharp.
I see. the minimum VS to handle this is 16.6 Preview 2
Once you install the latest 16.6 preview (16.6.30105.148) it should work (at least it does on my machine 馃榾)
I don't suppose it would be possible to make OmniSharp pick up the MSBuild that .NET Core ships with?
you can do that by adding omnisharp.json with
{
"msbuild" : {
"UseLegacySdkResolver": true
}
}
Just out of curiosity, given the Legacy bit, what's the reason for not doing that by default?
In any case, it seems that adding that setting to my project's omnisharp.json has no effect. It still locates the same MSBuild instances that I posted above.
Also, a minimal installation of VS 2019 Preview with just Roslyn + MSBuild results in:
[info]: OmniSharp.MSBuild.Discovery.MSBuildLocator
Located 3 MSBuild instance(s)
1: Visual Studio Community 2019 16.5.30011.22 - "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin"
2: Visual Studio Community 2019 16.6.30105.148 - "C:\Program Files (x86)\Microsoft Visual Studio\2019\Preview\MSBuild\Current\Bin"
3: StandAlone 16.4 - "C:\Users\alex\.vscode\extensions\ms-dotnettools.csharp-1.21.18\.omnisharp\1.35.1\.msbuild\Current\Bin"
[info]: OmniSharp.MSBuild.Discovery.MSBuildLocator
Registered MSBuild instance: Visual Studio Community 2019 16.5.30011.22 - "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin"
Can I tell OmniSharp which one to use? I'd rather not have to uninstall the stable version of VS 2019.
sorry, I thought you asked about how to use the SDK resolver that ships with dotnet SDK 馃檲
you can force a custom msbuild using these settings https://github.com/OmniSharp/omnisharp-roslyn/pull/1545#issuecomment-510461836
however, 16.6 should be picked before 16.5 - it does so on my machine at least (and the sample you posted also works then), so looks like it's non deterministic. I will check that
@filipw I am also having this issue with https://github.com/PowerShell/PowerShell project.
[info]: OmniSharp.MSBuild.Discovery.MSBuildLocator
Located 3 MSBuild instance(s)
1: Visual Studio Community 2019 16.5.30011.22 - "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin"
2: Visual Studio Community 2019 16.6.30105.148 - "C:\Program Files (x86)\Microsoft Visual Studio\2019\Preview\MSBuild\Current\Bin"
3: StandAlone 16.4 - "C:\Users\MD\.vscode\extensions\ms-dotnettools.csharp-1.21.18\.omnisharp\1.35.1\.msbuild\Current\Bin"
[info]: OmniSharp.MSBuild.Discovery.MSBuildLocator
Registered MSBuild instance: Visual Studio Community 2019 16.5.30011.22 - "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin"
Using instructions at https://github.com/OmniSharp/omnisharp-roslyn/pull/1545#issuecomment-510461836, I inserted the following in %USERPROFILE%\.omnisharp\omnisharp.json to resolve my issue:
{
"MSBuild": {
"MSBuildOverride": {
"MSBuildPath": "C:\\Program Files (x86)\\Microsoft Visual Studio\\2019\\Preview\\MSBuild\\Current\\Bin",
"Name": "Overridden MSBuild"
}
}
}
Most helpful comment
sorry, I thought you asked about how to use the SDK resolver that ships with dotnet SDK 馃檲
you can force a custom msbuild using these settings https://github.com/OmniSharp/omnisharp-roslyn/pull/1545#issuecomment-510461836
however, 16.6 should be picked before 16.5 - it does so on my machine at least (and the sample you posted also works then), so looks like it's non deterministic. I will check that