Build failure in VS2017

Hi Remco, sorry I cannot submit this through a bug report: The internet at my clients is rather restricted.

When opening the solution and waiting for NCrunch to load triggers this problem, across multiple projects in the solution. The same solution (same code and location), in VS2015 with NCrunch 3.5.0.1 loads and crunches tests no problem.

Here is a stack trace from one of the (many) failing projects:

NCrunch was unable to parse this project file because of an unexpected error: System.IO.FileNotFoundException: Could not load file or assembly 'System.Collections.Immutable, Version=1.2.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.
File name: 'System.Collections.Immutable, Version=1.2.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
   at Microsoft.Build.Evaluation.LazyItemEvaluator`4.ProcessItemElement(String rootDirectory, ProjectItemElement itemElement, Boolean conditionResult)
   at Microsoft.Build.Evaluation.Evaluator`4.EvaluateItemElement(Boolean itemGroupConditionResult, ProjectItemElement itemElement, LazyItemEvaluator`4 lazyEvaluator)
   at Microsoft.Build.Evaluation.Evaluator`4.EvaluateItemGroupElement(ProjectItemGroupElement itemGroupElement, LazyItemEvaluator`4 lazyEvaluator)
   at Microsoft.Build.Evaluation.Evaluator`4.Evaluate()
   at Microsoft.Build.Evaluation.Project.Reevaluate(ILoggingService loggingServiceForEvaluation, ProjectLoadSettings loadSettings)
   at Microsoft.Build.Evaluation.Project.ReevaluateIfNecessary(ILoggingService loggingServiceForEvaluation, ProjectLoadSettings loadSettings)
   at Microsoft.Build.Evaluation.Project.Initialize(IDictionary`2 globalProperties, String toolsVersion, String subToolsetVersion, ProjectLoadSettings loadSettings)
   at Microsoft.Build.Evaluation.Project..ctor(XmlReader xmlReader, IDictionary`2 globalProperties, String toolsVersion, String subToolsetVersion, ProjectCollection projectCollection, ProjectLoadSettings loadSettings)
   at Microsoft.Build.Evaluation.Project..ctor(XmlReader xmlReader, IDictionary`2 globalProperties, String toolsVersion, ProjectCollection projectCollection, ProjectLoadSettings loadSettings)
   at nCrunch.VSIntegration2010.MSBuildIntegration.BuildableProject2010.Initialise(BuildXml buildXml, FilePath projectFilePath, IDictionary`2 globalProperties)
   at nCrunch.Compiler.RemoteBuildRunner.(ComponentBuildParameters )
   at nCrunch.Compiler.RemoteBuildRunner..()
   at nCrunch.Common.PerformanceTracking.PerfTracker.TrackActivity(String name, Action activity)
   at nCrunch.Compiler.RemoteBuildRunner.(ComponentBuildParameters )

WRN: Assembly binding logging is turned OFF.
To enable assembly bind failure logging, set the registry value [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1.
Note: There is some performance penalty associated with assembly bind failure logging.
To turn this feature off, remove the registry value [HKLM\Software\Microsoft\Fusion!EnableLog].

Hi, thanks for sharing this problem.

VS2017 introduced a complex change to MSBuild dependency resolution under which the references are no longer stored in the GAC. This means they can only be loaded from known locations. The IDE works around this problem through a series of binding redirections in the devenv.exe.config file pointing to the common MSBuild dependencies.

It isn't clear to me why this particular reference isn't being found on your machine. The reference isn't normally included in the list of binding redirections. If I can get hold of a project that can cause this problem I should be able to track it down.

Most likely the problem is related to a specific build import or package dependency you have installed. Are you using any NuGet packages that may include custom build steps? Are you able to recreate the problem in a sample project you can share with me?

I'll try, it's a fairly large solution with a lot of NuGet packages, so it might take a little while to narrow down which one is causing the problem.

I've spent an hour trying to reproduce this in a test project, and I must admit I'm struggling to do so.

One of the projects in the main solution has a different stacktrace in the Trace Ouput window:

..\..\..\..\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Roslyn\Microsoft.CSharp.Core.targets (71, 5): Unexpected exception: 
..\..\..\..\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Roslyn\Microsoft.CSharp.Core.targets (71, 5): System.IO.FileNotFoundException: Could not load file or assembly 'System.IO.Pipes, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.
..\..\..\..\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Roslyn\Microsoft.CSharp.Core.targets (71, 5): File name: 'System.IO.Pipes, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
..\..\..\..\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Roslyn\Microsoft.CSharp.Core.targets (71, 5): at Microsoft.CodeAnalysis.CommandLine.BuildServerConnection.RunServerCompilationCore(RequestLanguage language, List`1 arguments, BuildPathsAlt buildPaths, String pipeName, String keepAlive, String libEnvVariable, Nullable`1 timeoutOverride, Func`3 tryCreateServerFunc, CancellationToken cancellationToken)
..\..\..\..\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Roslyn\Microsoft.CSharp.Core.targets (71, 5): at Microsoft.CodeAnalysis.CommandLine.BuildServerConnection.RunServerCompilation(RequestLanguage language, List`1 arguments, BuildPathsAlt buildPaths, String keepAlive, String libEnvVariable, CancellationToken cancellationToken)
..\..\..\..\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Roslyn\Microsoft.CSharp.Core.targets (71, 5): at Microsoft.CodeAnalysis.BuildTasks.ManagedCompiler.ExecuteTool(String pathToTool, String responseFileCommands, String commandLineCommands)
..\..\..\..\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Roslyn\Microsoft.CSharp.Core.targets (71, 5): WRN: Assembly binding logging is turned OFF.
..\..\..\..\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Roslyn\Microsoft.CSharp.Core.targets (71, 5): To enable assembly bind failure logging, set the registry value [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1.
..\..\..\..\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Roslyn\Microsoft.CSharp.Core.targets (71, 5): Note: There is some performance penalty associated with assembly bind failure logging.
..\..\..\..\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Roslyn\Microsoft.CSharp.Core.targets (71, 5): To turn this feature off, remove the registry value [HKLM\Software\Microsoft\Fusion!EnableLog].

This seems strange, System.IO.Pipes is not used anywhere in the solution.

I'll try and dig some more into this later on, but for now, it's back to VS2015.

Sorry, I wish I had an easy way to figure out what was happening here :(

Somewhere there must be logic telling the build system where to find these files. Please do let me know if you manage to isolate this problem.

Remco wrote:Sorry, I wish I had an easy way to figure out what was happening here :(

It's not your fault! I mostly blame my clients wacky solution and architecture choices :)