Unable to find 15.0 toolset in a project with MSBuild in it's name.

[srivatsn]

Repro steps:

• Create a project called "MSBuildTest" (or something with msbuild in the name) and reference the Microsoft.Build package.
• Add the following code

        static void Main(string[] args)
        {
            AppDomain.CurrentDomain.AssemblyResolve += (sender, eventArgs) =>
            {
                string msbuildPath = @"C:\Program Files (x86)\Microsoft Visual Studio\D15PreRel\MSBuild\15.0\Bin\";
                var targetAssembly = Path.Combine(msbuildPath, new AssemblyName(eventArgs.Name).Name + ".dll");
                return File.Exists(targetAssembly) ? Assembly.LoadFrom(targetAssembly) : null;
            };
            Run();
        }

        private static void Run()
        {
            ProjectCollection collection = new ProjectCollection();
            var project = collection.LoadProject(@"ConsoleApp.csproj");
        }

• Make sure there's a ConsoleApp.csproj which has ToolsVersion="15.0" in it.

Expected: The project should loaded fine.

Found: Throws

Microsoft.Build.Exceptions.InvalidProjectFileException: 'The tools version "15.0" is unrecognized. Available tools versions are "2.0", "3.5", "4.0".  ConsoleApp.csproj'

This is because BuildEnvironmentHelper tries to ascertain the mode in which msbuild is launched and one of the checks it does is to look at the process name and sees if it contains “MSBuild”. In this case, it think the BuildMode is Standalone and doesn't read msbuild.exe.config and hence doesn't get the 15.0 toolset.

[rainersigwald]

Relevant code is here

Path.GetFileNameWithoutExtension(processName)?
  .IndexOf(s, StringComparison.OrdinalIgnoreCase) >= 0);

Could be .Equals(s, StringComparison.OrdinalIgnoreCase) for this case, but not the test-runner cases. Maybe we could switch it up to be a regex match?

[rainersigwald]

I hoped that setting the environment variable MSBUILD_EXE_PATH would work around this, but it doesn't, because that always defaults to standalone mode, which is the problem here.

[williamb1024]

The same problem occurs if the process's image name contains DEVENV or BLEND.

[kzu]

Running

Microsoft Visual Studio Enterprise 2017 Int Preview
Version 15.3.0 Preview 3.0 [26620.0.d15rel]
VisualStudio.15.IntPreview/15.3.0-pre.3.0+26620.0.d15rel

and still seeing this in an xunit test running through the xunit.runner.visualstudio runner from within the VSTS test explorer.

[jairbubbles]

I stumbled into it too... thanks for reporting it.

I guess the first thing you do to test that lib is to create a MsBuild test application with MsBuild in the name...

[weltkante]

While the IsProcessInList heuristic is broader than it needs to be, the actual problem is that most of the TryFromXXX methods rely on a single heuristic and then return a BuildEnvironment without double checking if it actually is a valid one. This causes the calling loop to break the chain of try-methods and return an invalid build environment. Since heuristics can always have false-positives, validating the guess would be a more robust fix than just making IsProcessInList more strict.

[DustinCampbell]

I've run into this too. Great find!

[DustinCampbell]

Forgot about this problem and just ran into it again. 😄

[jairbubbles]

Well maybe we should add a link to this issue in the exception 😄

[DustinCampbell]

Well, the exception is that it can't find the toolset, so that's a bit heavy handed. 😸