-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
.NET Core App fails to load project (.NET 4.6.1 works as expected) #3434
Comments
Can you see if the documentation at https://docs.microsoft.com/en-us/visualstudio/msbuild/updating-an-existing-application helps? Feedback welcome, but I think it addresses your use case. |
The documentation suggests it would, but I can't access the |
When I run the project from the command line (using
The only |
I can confirm that it doesn't work when Paul's app that uses MSBuild is targeting netcoreapp20:
Looks like in both cases it's appending an unnecessary Adding some SDK experts @dsplaisted @nguerrera. Still not sure if the bug is in the SDK or elsewhere, but hopefully someone can shed some light. The repro is easy (just had to change the hardcoded path to the test project on Paul's drive). |
It is becoming more and more required, depending on the porting to the .net core. |
I just hit this issue. Are there any known workarounds? |
MSBuildLocator now supports .NET Core applications. Are you using it, @Alxandr? |
I'm using |
I tried doing the following: using System;
using System.Collections.Generic;
using System.Text;
static class Program
{
public static int Main()
{
Microsoft.Build.Locator.MSBuildLocator.RegisterDefaults();
return Build.Run();
}
} And I still got the same error. Here's output from the immediate window before doing
Edit: |
Any news on this issue? |
As far as I know MSBuildLocator should work on .NET Core. I'm not sure what the issue with nuke-build was, or whether it's been resolved yet. |
It should, yes. @Alxandr, would you mind sharing the version of your repro that used MSBuildLocator? |
I don't even remember which project I was using this on anymore, so I'm not going to to try to recreate it half a year later, sorry. |
I can still easily reproduce the problem: Use this .csproj: <Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>net5.0</TargetFramework>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.Build" Version="16.8.0" />
<PackageReference Include="Microsoft.Build.Utilities.Core" Version="16.8.0" />
</ItemGroup>
</Project> and this .cs: using Microsoft.Build.Evaluation;
class Program
{
private static void Main(string[] args)
{
var buildEngine = new ProjectCollection();
var project = buildEngine.LoadProject("some.csproj");
}
} It works fine if you're targeting net472, but fails if you're targeting net5.0. To workaround, you need to add a reference to Microsoft.Build.Locator. Change the .csproj to this: <Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>net5.0</TargetFramework>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.Build" Version="16.8.0" ExcludeAssets="runtime" />
<PackageReference Include="Microsoft.Build.Locator" Version="1.4.1" />
<PackageReference Include="Microsoft.Build.Utilities.Core" Version="16.8.0" ExcludeAssets="runtime"/>
</ItemGroup>
</Project> and the .cs to this: using Microsoft.Build.Evaluation;
class Program
{
private static void Main(string[] args)
{
Microsoft.Build.Locator.MSBuildLocator.RegisterDefaults();
Test();
}
private static void Test()
{
var buildEngine = new ProjectCollection();
var project = buildEngine.LoadProject("C:\\temp\\multi\\a\\a.csproj");
}
} Note how the first usage of MSBuild API has to be in a separate method, because otherwise JIT will try to resolve Microsoft.Build.dll before MSBuildLocator was registered. I'm still curious why the desktop version works without MSBuildLocator, but .NET 5 version needs it. |
The part of this that confuses me is not that it doesn't work with .NET 5 but that it works with .NET Framework. It's meaningless to say you need __ part of the MSBuild API if you don't specify which version of MSBuild you want to use. That suggests to me that there's some default logic that tries to guess which MSBuild you are trying to use, in which case it would make sense that it would only be right if it knows what framework to use, and it presumably hasn't been updated since Core came out. I'm curious what would happen if you tried it on a computer with Core MSBuild but not Framework MSBuild. |
For me everything works with .net 5.0, but as soon as I use .net 6.0 I have to use any updates on this issue (at least for .net 6.0)? |
What versions of MSBuild do you have? If you have net5.0 and net6.0 but nothing lower, that might validate my guess. |
I will check tomorrow, but I have VS 2019 and VS 2022 installed. .net core 3, .net 5 and .net 6.0 SDKs and runtimes. I also have.net 4.7.2 installed. |
Ah, ok. Not what I'd been hoping, then. Thanks for checking. |
I created a sample .NET Console app with the following code.
My project references the following 2 Nuget packages:
This gives the following exception when compiled to target .NET Core 2.0;
However it works as expected when targeting .NET 4.6.1
Any ideas?
ConsoleApp25.zip
The text was updated successfully, but these errors were encountered: