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

Notification

Icon
Error

How do I tell the grid node not to use the preview version of Visual Studio 2019
Magnus Lidbom
#1 Posted : Tuesday, July 14, 2020 8:16:27 AM(UTC)
Rank: Member

Groups: Registered
Joined: 8/30/2012(UTC)
Posts: 19

Thanks: 3 times
Was thanked: 4 time(s) in 4 post(s)
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?

Remco
#2 Posted : Tuesday, July 14, 2020 8:36:31 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 6,117

Thanks: 794 times
Was thanked: 1043 time(s) in 993 post(s)
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.
1 user thanked Remco for this useful post.
Magnus Lidbom on 7/14/2020(UTC)
Magnus Lidbom
#3 Posted : Tuesday, July 14, 2020 9:23:07 AM(UTC)
Rank: Member

Groups: Registered
Joined: 8/30/2012(UTC)
Posts: 19

Thanks: 3 times
Was thanked: 4 time(s) in 4 post(s)
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:

Code:

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.
Magnus Lidbom
#4 Posted : Tuesday, July 14, 2020 9:43:13 AM(UTC)
Rank: Member

Groups: Registered
Joined: 8/30/2012(UTC)
Posts: 19

Thanks: 3 times
Was thanked: 4 time(s) in 4 post(s)
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!
Remco
#5 Posted : Tuesday, July 14, 2020 12:33:48 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 6,117

Thanks: 794 times
Was thanked: 1043 time(s) in 993 post(s)
Magnus Lidbom;14871 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.
Magnus Lidbom
#6 Posted : Tuesday, July 14, 2020 1:00:33 PM(UTC)
Rank: Member

Groups: Registered
Joined: 8/30/2012(UTC)
Posts: 19

Thanks: 3 times
Was thanked: 4 time(s) in 4 post(s)
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.
Remco
#7 Posted : Tuesday, July 14, 2020 1:32:59 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 6,117

Thanks: 794 times
Was thanked: 1043 time(s) in 993 post(s)
Magnus Lidbom;14874 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.
Magnus Lidbom
#8 Posted : Tuesday, July 14, 2020 4:21:12 PM(UTC)
Rank: Member

Groups: Registered
Joined: 8/30/2012(UTC)
Posts: 19

Thanks: 3 times
Was thanked: 4 time(s) in 4 post(s)
Ah, then it all makes sense. Thank you for taking the time to explain :)
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.049 seconds.