Hi, thanks for sharing these issues.

It looks to me like many of these points are heading towards the same basic issue (management of grid server addresses across clients). Although I'm not sure if I can give you a direct solution to these problems at the moment, I can share a bit more information about the intentions of the NCrunch grid and how it saves server addresses under the hood.

NCrunch currently has two different ways of storing grid addresses:

1. Globally - This is inside the globalconfig.crunch.xml file usually stored under C:\Users\[USER]\AppData\Roaming\NCrunch. The file has an XML element called 'GridNodeAddresses'. Although much of the content of this element isn't really human readable (the server passwords are hashed/encrypted), it's still a text element that can be copied around between machines. NCrunch will always read from this file when it first loads.

2. Solution-Specific - This is inside the solution.v2.ncrunchsolution file adjusted to your .sln. There is an XML element here called 'GridNodeAddresses' which is basically identical to the one in the global NCrunch config file, but it is intended to be solution-specific and can be checked into a VCS.

When adding a node to your list of servers in the Distributed Processing Window, NCrunch will allow you to choose whether you wish the node to be stored globally or per-solution (or both). This will decide which config file the NCrunch will store the address in.

It is theoretically possible to write an app or script that could automatically update your list of grid nodes inside the NCrunch config file(s). As long as this update was made while the engine is offline, NCrunch should pick up the change and roll with it.

There is no feature in NCrunch that allows grouping of grid nodes in any sense ... although the UI does allow multiple selection. If you want a quick way to enable/disable grid nodes, I'd recommend adding a grouping prefix to their name so that they exist in the list adjacent to each other. In this way, you can just multi-select the 'groups' of servers easily in the list and disconnect/connect as you need to.

I'd be interested in learning more about why you need to manually disconnect/connect from/to different categories of nodes depending upon their O/S. This wasn't a use case that was expected when the distributed processing was designed.

When the NCrunch distributed processing was designed, included in the design was the concept of a 'grid controller' which would fill the role as a directory service, allowing grid nodes to sign on and off. Instead of managing their own lists of nodes, grid clients could just connect to the controller and would be fed the master list of nodes to connect to. The controller was also planned for other possible features to make the grid more powerful and configurable. Unfortunately, it fell out of scope as the first release of the distributed processing was simply too complex and I wasn't sure if the grid support would be popular enough to warrant an extra component. The good news is that NCrunch distributed processing is becoming quote widespread now and the controller is looking more worthwhile. The only hard part is finding the time to implement it. This has been a difficult year for NCrunch, with many big changes in the eco-system (VS2015, Xunit V2, NUnit V3, DNX, etc).

NCrunch v2.17 has just been released with a new feature that I hope will help with the multi-platform testing you've described. Check it out - http://blog.ncrunch.net/post/NUnit-V3-Distributed-Processing-Upgrades-and-Lots-of-fixes.aspx.