Microsoft.Build.Evaluation（快进到 2021 年）的正确用法是什么？

Question

So the original question What's the correct usage of Microsoft.Build.Evaluation? has the following accepted answer:

project = new Project(projectPath, new Dictionary<string, string>(), "12.0", new ProjectCollection());

This does not work in 2021 with NuGet package Microsoft.Build 16.8.0.

I would like to evaluate a non SDK style project like this:

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="14.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <Import Project="$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props" />
...
  <Import Project="..\..\..\Tools\MSBuild\Dayforce.targets" />
  <Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />
</Project>

Please, observe:

Attempt 1

new Project(projectPath, new Dictionary<string, string>(), "16.0", new ProjectCollection());

Results in:

Microsoft.Build.Exceptions.InvalidProjectFileException: The tools version "16.0" is unrecognized. Available tools versions are "Current".

Attempt 2

new Project(projectPath, new Dictionary<string, string>(), "Current", new ProjectCollection());

Results in:

Microsoft.Build.Exceptions.InvalidProjectFileException: The imported project "C:\work\CSTool\CSTool\bin\Debug\netcoreapp3.1\Current\Microsoft.Common.props" was not found. Confirm that the expression in the Import declaration "C:\work\CSTool\CSTool\bin\Debug\netcoreapp3.1\Current\Microsoft.Common.props" is correct, and that the file exists on disk.

Attempt 3

new Project(projFilePath, new Dictionary<string, string>
{
    ["MSBuildExtensionsPath"] = @"C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild",
}, "Current", new ProjectCollection());

Results in:

Microsoft.Build.Exceptions.InvalidProjectFileException: The imported project "C:\work\CSTool\CSTool\bin\Debug\netcoreapp3.1\Microsoft.CSharp.targets" was not found. Confirm that the expression in the Import declaration "C:\work\CSTool\CSTool\bin\Debug\netcoreapp3.1\Microsoft.CSharp.targets" is correct, and that the file exists on disk. 

We are making progress, Microsoft.Common.props seems to have been imported and now we fail on the last import - Microsoft.CSharp.targets

Attempt 4

new Project(projFilePath, new Dictionary<string, string>
{
    ["MSBuildExtensionsPath"] = @"C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild",
    ["MSBuildBinPath"] = @"C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Bin",
}, "Current", new ProjectCollection());

But the result is:

System.ArgumentException: The "MSBuildBinPath" property name is reserved.

So, what am I missing?

I managed to do what I wanted. However, none of the Microsoft.Build NuGet packages worked as expected by me. I checked all the published versions.

What worked for me is reference the Microsoft.Build Dlls found inside the VS 2019 installation directory. Here is my project file:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp3.1</TargetFramework>
  </PropertyGroup>

  ...

  <ItemGroup>
    <Reference Include="Microsoft.Build">
      <HintPath>..\..\..\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Bin\Microsoft.Build.dll</HintPath>
    </Reference>
    <Reference Include="Microsoft.Build.Framework">
      <HintPath>..\..\..\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Bin\Microsoft.Build.Framework.dll</HintPath>
    </Reference>
    <Reference Include="Microsoft.Build.Utilities.Core">
      <HintPath>..\..\..\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Bin\Microsoft.Build.Utilities.Core.dll</HintPath>
    </Reference>
  </ItemGroup>

</Project>

And here is the code that works:

var project = new Project(projFilePath);
foreach (var compileItem in project.AllEvaluatedItems.Cast<ProjectItem>().Where(item => item.ItemType == "Compile"))
{
    var filePath = compileItem.EvaluatedInclude;
    ...
}

I checked the msbuild github repository - it does not use the NuGet packages either. Instead it includes the source code for all the relevant libraries and just builds them. And these dlls work too just as the VS dlls work.

So, what is the deal with the NuGet packages? I do not get it. Opened https://github.com/dotnet/msbuild/issues/6147

Answer 1

You need to reference the Microsoft.Build.Utilities.Core NuGet package and also set the MSBUILD_EXE_PATH environment variable to either MSBuild.exe or MSBuild.dll

https://web.archive.org/web/20210419051516/https://blog.rsuter.com/missing-sdk-when-using-the-microsoft-build-package-in-net-core/

After this just create a project:

var project = new Project("Path\To\Your\Project");

Answer 2

There are couple of scenarios.

• You want to use the .NET Core SDK installed under C:\Program Files\dotnet . In this case the following code works for me:

var msbuildDllPath = Path.Combine(sdkPath, "msbuild.dll");
Environment.SetEnvironmentVariable("MSBUILD_EXE_PATH", msbuildDllPath);
Environment.SetEnvironmentVariable("MSBuildExtensionsPath32", sdkPath);
Environment.SetEnvironmentVariable("MSBuildExtensionsPath64", sdkPath);
Environment.SetEnvironmentVariable("MSBuildExtensionsPath", sdkPath);

var project = new Project(projectPath, null, "Current", new ProjectCollection(ToolsetDefinitionLocations.Local));

This is the only combination that I could find to work for this scenario. The TargetFramework of the code itself is net5.0

• You want to use the build tools associated with the Visual Studio in the PATH, but it could be 2017 or 2019 or 2017, when also 2019 is installed. This is a real PITA and the solution is not pretty. Here is what worked for me:

private static (string, string) GetMostRecentMSBuildExePath()
{
    var flavors = new[]
    {
        "Professional",
        "Enterprise",
        "Community",
        "BuildTools",
    };

    string found = null;
    int maxVersion = 2017;
    foreach (var drive in DriveInfo.GetDrives().Where(o => o.DriveType == DriveType.Fixed))
    {
        foreach (var dir in Directory.GetDirectories(drive.Name + "Program Files (x86)\\Microsoft Visual Studio"))
        {
            if (!int.TryParse(dir.Substring(dir.Length - 4), out var version) || version <= maxVersion)
            {
                continue;
            }
            var msbuildExePath = flavors.Select(flavor => dir + "\\" + flavor + "\\MSBuild\\Current\\bin\\msbuild.exe").FirstOrDefault(File.Exists);
            if (msbuildExePath != null)
            {
                maxVersion = version;
                found = msbuildExePath;
            }
        }
    }

    string vsVersion = null;
    if (found != null)
    {
        foreach (var dir in Directory.GetDirectories(found + @"\..\..\..\Microsoft\VisualStudio", "v*"))
        {
            if (Directory.Exists(dir + "\\WebApplications"))
            {
                var index = dir.LastIndexOf("\\");
                vsVersion = dir.Substring(index + 2);
                break;
            }
        }
    }
    return (found, vsVersion);
}

...
// Check if VSINSTALLDIR implicates 2017.
// If not - we are good.
// If yes - search if there is VS 2019 in any of the well known locations.
// If yes - point at it, if no - leave as is.

string toolsVersion = null;
var vsInstallDir = Environment.GetEnvironmentVariable("VSINSTALLDIR");
if (vsInstallDir?.Contains("\\2017\\") == true)
{
    // Bummer. Check if 2019 or up is installed.
    var (msBuildExePath, vsVersion) = GetMostRecentMSBuildExePath();
    if (msBuildExePath == null)
    {
        // Only VS 2017
        toolsVersion = "15.0";
        Environment.SetEnvironmentVariable("MSBUILD_EXE_PATH", Path.Combine(vsInstallDir, "MSBuild\\15.0\\bin\\msbuild.exe"));
    }
    else
    {
        toolsVersion = "Current";
        Environment.SetEnvironmentVariable("MSBUILD_EXE_PATH", msBuildExePath);
        Environment.SetEnvironmentVariable("VisualStudioVersion", vsVersion);
    }
}

var project = new Project(projectFilePath, null, toolsVersion);

In this case TargetFramework of the code is net472 . I also assume VS is installed in a standard location, albeit on any drive.