How do I tell the grid node not to use the preview version of Visual Studio 2019

Hi,

I'm getting the warning about build results being inconsistent across the grid. So I compared the contents of the buildsystem folder on the different grid nodes and found that on one all the config files were using paths belonging to the preview version of visual studio. I cannot find any option in the grid node configuration that lets me tell it not to use the preview version. How can I resolve this?

Hi, thanks for posting.

To handle this, you need to set an environment variable on the machine to tell NCrunch which version of VS to use.

Set 'NCrunchVSInstallPath.VS2019' to the installation directory of the version of VS you want, i.e. 'C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise'.

You'll need to restart the NCrunch grid node service when you've done this, and maybe reboot the machine.

Thank you. I wish I could tell you that that solved everything for me. But impatient as I am I had already uninstalled the preview version of visual studio. And that apparently made NCrunch break badly. I'm now getting this exception for every project in my solution:

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 target "_SplitProjectReferencesByFileExistence" does not exist in the project.
   at nCrunch.Compiler.ComponentAnalysisContext.()
   at nCrunch.Compiler.ComponentAnalysisContext.AnalyseComponentBuild()
   at nCrunch.Compiler.RemoteBuildRunner.AnalyseComponentBuild(ComponentLoadParameters parameters)
   --- 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.(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(ComponentLoadParameters parameters)
   at nCrunch.Core.BuildManagement.BuildProcessLauncher..(IRemoteBuildRunner )
   at nCrunch.Core.BuildManagement.BuildProcessLauncher.(Action`1 , FilePath , String , ExternalProcess )
   at nCrunch.Core.BuildManagement.BuildProcessLauncher.(Action`1 , EffectiveProcessorArchitecture , GridClientId , BuildSystemParameters , IList`1 , Nullable`1 , GridAddress )
   at nCrunch.Core.BuildManagement.BuildProcessLauncher.AnalyseComponentBuildInExternalProcess(ComponentLoadParameters parameters, IList`1 customEnvironmentVariables)
   at nCrunch.Client.ComponentLoader.SnapshotComponentLoader.(EffectiveProcessorArchitecture , String )
   at nCrunch.Client.ComponentLoader.SnapshotComponentLoader.CreateComponentFromXml(FilePath projectFilePath, ParsedBuildXml projectXml, FilePath solutionFilePath, String[] additionalFilesToIncludeAtSolutionLevel, Boolean isLoadedFromFile, VisualStudioVersion vsVersion, ComponentUniqueName componentName, TaskSettings componentTaskSettings, Exception parseException, String targetFramework)

I've tried everything I can think of. Emptying the ncrunch folders in Appdata, the ncrunch cache folder, the workspaces folder, Reinstalling, git clean -f -d -x. Nothing works. Please help.

OK so I did the obvious thing, though I did not want to, and reinstalled the preview of Visual Studio. This did revive NRunch in the stable version of visual studio. This was a relief, but I hardly think this is how things should be!

Magnus Lidbom wrote:OK so I did the obvious thing, though I did not want to, and reinstalled the preview of Visual Studio. This did revive NRunch in the stable version of visual studio. This was a relief, but I hardly think this is how things should be!

It's likely that installing/uninstalling the preview version has somehow messed with the paths being used by MSBuild internally. The error you've received is a generic one kicked up by MSBuild when it can't find its targets. Unfortunately although we can control which version of VS/MSBuild we reference with NCrunch, we can't build with it if MSBuild has internal issues. There may be cross configuration between the preview version you have installed and the stable one. Reinstalling both may help, but generally I would advise keeping only one of them on the system... having two versions of VS installed on a machine can make for some strange issues with tooling.

Agreed about keeping both installed. That's why i said I did not want to reinstall the preview version. It was the only way I could find to get things working though.
If I find the time, energy, and courage to face total breakage again, I might try uninstalling the preview version and reinstalling the production version and see if NCrunch works then.

However, It was only NCrunch that had any problems with building. Visual studio was building everything just fine. And having both installed is, according to Microsoft, perfectly fine. So my personal opinion is that I, if I were you, would treat this as a bug that should at least get some time spent researching it. Installing and uninstalling the preview version can hardly be all that unusual.

Just my 2 cents.

Magnus Lidbom wrote:
However, It was only NCrunch that had any problems with building. Visual studio was building everything just fine. And having both installed is, according to Microsoft, perfectly fine. So my personal opinion is that I, if I were you, would treat this as a bug that should at least get some time spent researching it. Installing and uninstalling the preview version can hardly be all that unusual.

We do test for this, and design for it. Our dev environments are all dual version (preview/stable, sometimes others too). NCrunch should work in this scenario. However ...

The problem itself is baked into the infrastructure. We don't know how to reproduce it, because it doesn't appear for us under the same described conditions.

VS and MSBuild are frightfully complex beasts. Trying to understand why this isn't working on your system would likely require a very time consuming investigation that might even require access to the machine to trace why the build is behaving in this way. When the likely fix would be a change to the infrastructure (and not NCrunch), there is little reason to pursue this. Instead the relevant focus is on finding a way to get NCrunch working for you.

Ah, then it all makes sense. Thank you for taking the time to explain :)