Welcome Guest! To enable all features please Login or Register.

Notification

Icon
Error
VS2017, NCrunch 3.2.0.3 build error
Options
Previous Topic Next Topic
metadata
#1 Posted : Tuesday, December 13, 2016 8:24:02 PM(UTC)
Rank: Newbie

Groups: Registered
Joined: 12/13/2016(UTC)
Posts: 5
Location: Croatia
System.Exception: An exception was thrown in the remote environment: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> nCrunch.Common.UserException: Errors occurred while trying to load the project file:
The "ResolveComReference" task could not be instantiated from "Microsoft.Build.Tasks.Core, Version=15.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a". Could not load file or assembly 'Microsoft.Build.Tasks.Core, Version=15.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.
The "ResolveComReference" task has been declared or used incorrectly, or failed during construction. Check the spelling of the task name and the assembly name.
at nCrunch.Compiler.RemoteBuildRunner.(FilePath ,   , String , String , DirectoryPath , String )
at nCrunch.Compiler.RemoteBuildRunner.AnalyseComponentBuild(FilePath projectFilePath, BuildXml buildXml, String useBuildConfiguration, String useBuildPlatform, DirectoryPath solutionDir, String solutionName, List`1 importExpressionsToEvaluate, ProcessorArchitecture buildProcessProcessorArchitecture, DirectoryPath workspaceBasePath)
--- End of inner exception stack trace ---
at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor)
at System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal(Object obj, Object[] parameters, Object[] arguments)
at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
at nCrunch.TaskRunner.Ipc.IpcMessageProcessor.(CallMethodMessage )
at nCrunch.TaskRunner.Ipc.IpcMessageProcessor.ProcessMessageReturningResult(Byte[] data)
at nCrunch.TaskRunner.Ipc.RemoteInstance.[T](Byte[] )
at nCrunch.TaskRunner.Ipc.RemoteInstance.Invoke(IMessage msg)
at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
at nCrunch.Compiler.IRemoteBuildRunner.AnalyseComponentBuild(FilePath projectFilePath, BuildXml buildXml, String useBuildConfiguration, String useBuildPlatform, DirectoryPath solutionDir, String solutionName, List`1 importExpressionsToEvaluate, ProcessorArchitecture buildProcessProcessorArchitecture, DirectoryPath workspaceBasePath)
at nCrunch.Core.BuildManagement.BuildProcessLauncher..(IRemoteBuildRunner )
at nCrunch.Core.BuildManagement.BuildProcessLauncher.(Action`1 , IBuildableProject , ExternalProcess )
at nCrunch.Core.BuildManagement.BuildProcessLauncher.(Action`1 , ProcessorArchitecture , GridClientId , IBuildableProject , IList`1 )
at nCrunch.Core.BuildManagement.BuildProcessLauncher.AnalyseComponentBuildInExternalProcess(FilePath projectFilePath, BuildXml buildXml, String useBuildConfiguration, String useBuildPlatform, DirectoryPath solutionDir, String solutionName, List`1 importExpressionsToEvaluate, ProcessorArchitecture processorArchitecture, VisualStudioVersion vsVersion, IList`1 customEnvironmentVariables)
at nCrunch.Client.ComponentLoader.SnapshotComponentFactory.(ProcessorArchitecture )
at nCrunch.Client.ComponentLoader.SnapshotComponentFactory.CreateSnapshotComponentFromXml(FilePath projectFilePath, BuildXml projectXml, FilePath solutionFilePath, String[] additionalFilesToIncludeAtSolutionLevel, Boolean isLoadedFromFile, VisualStudioVersion vsVersion)
Back to top
Remco
#2 Posted : Tuesday, December 13, 2016 10:59:15 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,145

Thanks: 960 times
Was thanked: 1290 time(s) in 1196 post(s)
Hi, thanks for sharing this issue.

When NCrunch creates a process to execute MSBuild, it does so using a temporary file called 'MSBuildConfigVS2017.config'. This file can be found at C:\Users\[USER]\AppData\Local\NCrunch. It contains a number of binding redirections that force the build system to use the correct versions of the MSBuild assemblies, while also telling the CLR where to find these files.

The file is generated automatically based on your VS2017 install. Would you be able to share the contents of this file as it exists on your machine? The bindings in the file should point to your MSBuild assemblies as they exist in your VS2017 installation, i.e. C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\*

It would also be worth checking whether these files exist under the path the file thinks they're under.
Back to top
metadata
#3 Posted : Wednesday, December 14, 2016 9:31:02 AM(UTC)
Rank: Newbie

Groups: Registered
Joined: 12/13/2016(UTC)
Posts: 5
Location: Croatia
Sure, content of the file is below. All listed files are present on the system.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v4.0" />
</startup>
<runtime>
<enforceFIPSPolicy enabled="false"/>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Microsoft.Build.Framework" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
<bindingRedirect oldVersion="2.0.0.0-99.0.0.0" newVersion="15.1.0.0"/>
<codeBase version="15.1.0.0" href="C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\Microsoft.Build.Framework.dll" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Microsoft.Build" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
<bindingRedirect oldVersion="2.0.0.0-99.0.0.0" newVersion="15.1.0.0"/>
<codeBase version="15.1.0.0" href="C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\Microsoft.Build.dll" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Microsoft.Build.Engine" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
<bindingRedirect oldVersion="2.0.0.0-14.0.0.0" newVersion="15.0.0.0"/>
<codeBase version="15.0.0.0" href="C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\Microsoft.Build.Engine.dll" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Microsoft.Build.Conversion.Core" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
<bindingRedirect oldVersion="2.0.0.0-14.0.0.0" newVersion="15.0.0.0"/>
<codeBase version="15.0.0.0" href="C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\Microsoft.Build.Conversion.Core.dll" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Microsoft.Build.Tasks.Core" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
<bindingRedirect oldVersion="2.0.0.0-99.0.0.0" newVersion="15.1.0.0"/>
<codeBase version="15.1.0.0" href="C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\Microsoft.Build.Tasks.Core.dll" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Microsoft.Build.Utilities.Core" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
<bindingRedirect oldVersion="2.0.0.0-99.0.0.0" newVersion="15.1.0.0"/>
<codeBase version="15.1.0.0" href="C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\Microsoft.Build.Utilities.Core.dll" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Microsoft.Build.Engine" culture="neutral" publicKeyToken="b03f5f7f11d50a3a" />
<bindingRedirect oldVersion="0.0.0.0-99.9.9.9" newVersion="15.1.0.0" />
<codeBase version="15.1.0.0" href="C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\Microsoft.Build.Engine.dll"/>
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Microsoft.Build.Conversion.Core" culture="neutral" publicKeyToken="b03f5f7f11d50a3a" />
<bindingRedirect oldVersion="0.0.0.0-99.9.9.9" newVersion="15.1.0.0" />
<codeBase version="15.1.0.0" href="C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\Microsoft.Build.Conversion.Core.dll"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>
Back to top
Remco
#4 Posted : Wednesday, December 14, 2016 10:16:17 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,145

Thanks: 960 times
Was thanked: 1290 time(s) in 1196 post(s)
Thanks for sharing these details.

Are there certain projects that seem to trigger this for you?

The binding redirections all look to be in order, so if the files exist in the referenced location, it isn't clear to me why the CLR would have trouble finding them.

Something worth trying is to turn on fusion logging to see if this traps any useful information for us.

This stack overflow answer explains how to turn on fusion logging: https://stackoverflow.com/questions/255669/how-to-enable-assembly-bind-failure-logging-fusion-in-net#1527249.

If you can get a fusion logging capture for me for the nCrunch.BuildHost46x.x86.exe when this happens, that would be really helpful.
Back to top
metadata
#5 Posted : Wednesday, December 14, 2016 11:29:28 AM(UTC)
Rank: Newbie

Groups: Registered
Joined: 12/13/2016(UTC)
Posts: 5
Location: Croatia
Back to top
Remco
#6 Posted : Wednesday, December 14, 2016 11:30:24 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,145

Thanks: 960 times
Was thanked: 1290 time(s) in 1196 post(s)
Thanks! This helps a great deal. I think I have some idea of what may be going on here, but it isn't clear to me why this is showing up in your case but not in others.

Is there a specific VS project template that can surface this issue for you?
Back to top
metadata
#7 Posted : Thursday, December 15, 2016 8:50:52 AM(UTC)
Rank: Newbie

Groups: Registered
Joined: 12/13/2016(UTC)
Posts: 5
Location: Croatia
It's happening in one of my most complex projects. I can't share it with you, unfortunately - and it depends on other projects. The same solution and projects work perfectly in VS2015's NCrunch.
If there is anything else I can do to help you troubleshoot - let me know.
Back to top
Remco
#8 Posted : Thursday, December 15, 2016 10:30:34 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,145

Thanks: 960 times
Was thanked: 1290 time(s) in 1196 post(s)
Ok, there may be something we can try here.

In your NCrunch for VS2017 installation directory you'll find a file, 'nCrunch.BuildHost462.x86.exe.config' (usually at C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\Extensions\Remco Software\NCrunch for Visual Studio 2017).

I'm wondering if you could try copying the binding redirections from the MSBuildConfigVS2017.config file into this file. From the fusion logs, it looks like the binding issue is happening in the primary appdomain .. which isn't right, but if it's true, then this may work around the problem.
Back to top
metadata
#9 Posted : Thursday, December 15, 2016 10:59:19 AM(UTC)
Rank: Newbie

Groups: Registered
Joined: 12/13/2016(UTC)
Posts: 5
Location: Croatia
This fixes the problem, thanks a lot for your persistence. I hope my manually editing of the config file won't break something in the future :)

For your reference, here are the contents of original file...:

<?xml version ="1.0"?>
<configuration>
<configSections>
<section name="msbuildToolsets" type="Microsoft.Build.BuildEngine.ToolsetConfigurationSection, Microsoft.Build.Engine, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
</configSections>
<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.6.2" />
</startup>
<runtime>
<legacyUnhandledExceptionPolicy enabled="1" />
<enforceFIPSPolicy enabled="false"/>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Microsoft.Build.Framework" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
<bindingRedirect oldVersion="0.0.0.0-99.9.9.9" newVersion="14.0.0.0"/>
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Microsoft.Build.Engine" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
<bindingRedirect oldVersion="0.0.0.0-99.9.9.9" newVersion="14.0.0.0"/>
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Microsoft.Build" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
<bindingRedirect oldVersion="0.0.0.0-99.9.9.9" newVersion="14.0.0.0"/>
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Microsoft.CompactFramework.Build.Tasks" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
<bindingRedirect oldVersion="0.0.0.0-99.9.9.9" newVersion="9.0.0.0"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>

... and manually edited file:

<?xml version ="1.0"?>
<configuration>
<configSections>
<section name="msbuildToolsets" type="Microsoft.Build.BuildEngine.ToolsetConfigurationSection, Microsoft.Build.Engine, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
</configSections>
<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.6.2" />
</startup>
<runtime>
<legacyUnhandledExceptionPolicy enabled="1" />
<enforceFIPSPolicy enabled="false"/>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Microsoft.Build.Framework" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
<bindingRedirect oldVersion="2.0.0.0-99.0.0.0" newVersion="15.1.0.0"/>
<codeBase version="15.1.0.0" href="C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\Microsoft.Build.Framework.dll" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Microsoft.Build" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
<bindingRedirect oldVersion="2.0.0.0-99.0.0.0" newVersion="15.1.0.0"/>
<codeBase version="15.1.0.0" href="C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\Microsoft.Build.dll" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Microsoft.Build.Engine" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
<bindingRedirect oldVersion="2.0.0.0-14.0.0.0" newVersion="15.0.0.0"/>
<codeBase version="15.0.0.0" href="C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\Microsoft.Build.Engine.dll" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Microsoft.Build.Conversion.Core" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
<bindingRedirect oldVersion="2.0.0.0-14.0.0.0" newVersion="15.0.0.0"/>
<codeBase version="15.0.0.0" href="C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\Microsoft.Build.Conversion.Core.dll" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Microsoft.Build.Tasks.Core" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
<bindingRedirect oldVersion="2.0.0.0-99.0.0.0" newVersion="15.1.0.0"/>
<codeBase version="15.1.0.0" href="C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\Microsoft.Build.Tasks.Core.dll" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Microsoft.Build.Utilities.Core" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
<bindingRedirect oldVersion="2.0.0.0-99.0.0.0" newVersion="15.1.0.0"/>
<codeBase version="15.1.0.0" href="C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\Microsoft.Build.Utilities.Core.dll" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Microsoft.Build.Engine" culture="neutral" publicKeyToken="b03f5f7f11d50a3a" />
<bindingRedirect oldVersion="0.0.0.0-99.9.9.9" newVersion="15.1.0.0" />
<codeBase version="15.1.0.0" href="C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\Microsoft.Build.Engine.dll"/>
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Microsoft.Build.Conversion.Core" culture="neutral" publicKeyToken="b03f5f7f11d50a3a" />
<bindingRedirect oldVersion="0.0.0.0-99.9.9.9" newVersion="15.1.0.0" />
<codeBase version="15.1.0.0" href="C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\Microsoft.Build.Conversion.Core.dll"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>
Back to top
Remco
#10 Posted : Thursday, December 15, 2016 11:11:29 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,145

Thanks: 960 times
Was thanked: 1290 time(s) in 1196 post(s)
That's great news! Thanks for confirming that this worked for you. I should be able to introduce a proper fix to this now.

NCrunch won't mind you manually editing the file, but installing any other version of the software will overwrite your changes. Hopefully v3.3 will include a fix anyway, so this may be the last you see of the problem.
Back to top
Remco
#11 Posted : Wednesday, January 18, 2017 11:46:01 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,145

Thanks: 960 times
Was thanked: 1290 time(s) in 1196 post(s)
NCrunch v3.3 is now available including a fix for this issue - https://www.ncrunch.net/download.
Back to top
Users browsing this topic
Guest
Forum Jump  
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.

YAF | YAF © 2003-2011, Yet Another Forum.NET
This page was generated in 0.105 seconds.
Trial NCrunch
Take NCrunch for a spin
Do your fingers a favour and supercharge your testing workflow
Free Download