Hi Sheryl,

If I understand your setup correctly, I think there may be a problem with the way the solution is being shared between the two jobs.

The NCrunch console runner is essentially just an end-to-end version of the VS addin. It will load the solution from disk and distribute it to the grid nodes by sequentially uploading files. If you are using the same solution for both jobs, and both jobs run concurrently, then any file modified in the NCrunch solution by one job will likely affect the other jobs, as NCrunch is uploading files to the grid nodes from the same place. It may be possible to delay the update of the run ID so that the first job has time to upload the unchanged files to the grid nodes, but you'll have no easy way of knowing when this upload is completed, so at best you'll end up with a giant race condition.



To reliably run the two jobs with different IDs, you'll need to have separate source solutions - one for each job. Otherwise, you may wish to try a different way of managing the run ID.. Perhaps using an environment variable?

On a grid node, NCrunch will always create a single snapshot for each client connection. This means that if you have two jobs running on the same node, you'll have two client connections and therefore two snapshots of the same solution. The snapshots, workspaces and tasks on the node are kept completely separate and should not interfere with each other. The grid node tracks each file in a snapshot individually, and it will clone the files locally where necessary to improve copy time and reduce reliance on the network. When the job finishes (or the connection is lost), the snapshots will persist on the grid node and will be updated and reused the next time a connection is accepted for a similar solution. In this way there is a minimum of files being copied, but you'll experience higher disk consumption if you have more jobs running concurrently.

I'm curious as to why you're taking the approach of introducing your own concurrency at a higher level above NCrunch. NCrunch itself is intended to be able to execute tests in parallel over the grid. If you use NCrunch's parallelisation features, you'll only need to set up a single job, and NCrunch will only need to build the solution once.



The only way I could think of doing this would be to use a different NCrunch configuration file for each run. The global NCrunch config file contains a XML element listing the grid nodes the engine is expected to connect to. You could use the '/c' command line option of the console tool to specify a different config file for each run, adjusting the list of grid nodes in each config file to point to those applicable to the run.

Thank you for the suggestion on using the different NCrunch configuration file for each run. This will be very helpful in controlling the distribution of test runs across grid nodes.