Occasionally our nodes show the following error. This is building a net472 project, but new SDK style csproj file format. VS is up to date (16.7.2), NCrunch is up to date (4.4.0.12) and the highest version of the .NET Core SDK we've got installed is 3.1.401
System.Exception: Component [SnapshotComponent: Ledgerscope.Data.xxx.xxx, 31, 66807606] does not have a local build output
at nCrunch.Core.Processing.BuildTaskLogic.PrepareForProcessing()
at nCrunch.Common.ErrorHandler.DoWithErrorHandling(Action action, Object context)
If there's anything else that would be useful to provide please let me know
This is likely going to be a tough one to track down.
When the error appears, does the system eventually rebuild the project and just carry on as usual?
Do you notice any pattern around the kind of changes you are making when the error appears? NCrunch has two kinds of changes that it tracks. The first is a text change to any file in the project. The second is when a project itself is changed (for example, when the XML of the .proj is affected or a new source file is added to the project). The latter is considerably more complex and involves a much larger sequence of sync messages between client and server. I'm trying to determine whether this problem can occur without any project changes happening, knowing this would be useful in narrowing the scope of where to look.
Does this seem to affect just one project, or are there others too?
We are chopping and changing a lot of our project stuff at the moment (we're in the midst of retargeting our projects to NETSTANDARD, and VS doesn't always require a restart). The main problem we have that makes this difficult to track down is that it's a server error as opposed to a session error, so we don't even know for which member of our team it was triggered.
It doesn't seem to cause us a problem in general though, it just causes a red exclamation mark to appear in the Distributed Processing window and as far as I'm aware it self recovers (although we have enough grid nodes and local processing that if one were to stop processing for any reason we may not even notice)
I'll see if we can spot a pattern with it, or if you think it would be useful then I'm happy to run one of our nodes with more verbose logging enabled to try and capture some more details
Based on what you've described, I think this may be a race condition that appears sometimes when a project file is modified while the grid node is cranking at full speed. Probably it's trying to process a task against the project while the grid node is reloading it. This is almost certainly benign. After the project has been resynchronised with the node, the task will be requeued and will execute as normal.
I expect we'll have a really hard time pinning this down in any way other than through a detailed code review. Perhaps try to keep an eye out on when it happens. If you can narrow it down for us, this will make finding it easier. Logs could be useful but with the level of activity happening on the grid nodes, we'd need a very wide net to have a chance of a diagnosis .. and your grid performance would be significantly worse with the logging enabled.