Sorry, it's hard for me to give advice on this as I'm not familiar with this particular toolset.



Not specifically, but this doesn't necessarily mean that it can't be made to work. No code exists in NCrunch to integrate with this toolset, but personally I wouldn't expect AI based toolsets to clash with NCrunch unless they are doing something odd.



Synchronisation with the project.assets.json file (and its derivatives) has always been slightly unreliable in NCrunch because of the way that VS refreshes them asynchronously after projects have loaded. There is a lot of logic to try and identify situations where this file changes and force the reload, but there still seems to be inconsistent edge cases in VS where the tracking needs a kick to reload itself. Normally this isn't a problem because projects.assets.json rarely changes during a session.

If you're seeing this, it means that something on your system is triggering constant project restore steps to be run. That's not something you want, as it causes a lot of stuff to move around which can cause intermittent downstream issues. It may be worth examining why this keeps happening to see if there's something you can do to prevent it from happening. I can't imagine your list of installed packages needs to change every few seconds.

Yes, the Windows-only limitation is starting to get much more painful now. AI seems to be naturally gravitating towards linux based setups.

As I've discussed much throughout this forum, Linux support is not in scope for NCrunch right now. It would theoretically be a massive piece of work, since the product was never designed with it in mind. There's a couple of things that give me some hope here though:
1. An AI-only version of NCrunch wouldn't need a GUI. Porting the GUI to Linux is the hardest part.
2. Agents are getting really good at handling these sorts of problems. I don't think we're quite there yet, but this may eventually be something I can task to an agent and have it perform two years worth of work autonomously.

So I'm hopeful. On my personal list of things I want from NCrunch, Linux support is at the top of the list. I make no promises right now.



I'm not sure if I completely understand the boundaries of this, but if we have an NCrunch grid node running on a Windows machine, doesn't that mean that the containerised agent has the ability to execute code outside the container? And wouldn't that be a security risk?

Without a Linux-capable grid node or MCP server, we don't have a way to let an agent run tests inside a Linux based container. The setup I'm using personally involves a Linux VM hosting the agent, which has broad access to a Windows based VM running the NCrunch MCP server with grid node. Access controls are then placed around the VMs using an external firewall. This seems to work well, though I honestly have no idea if such a setup would be allowed inside a larger organisation with more constraints.



I think it's reasonable to expect that there will be security and compliance standards establishing how agents should be controlled. I have to admit though that with the pace the technology is moving right now, the standards may simply be playing catch-up. There is probably more disruption coming. Some possibilities:
- What if model architectures develop the ability to cheaply train in real time? (i.e evolving intelligence)
- What if the massive push to build AI chips results in oversupply and prices crash? It might become economical for organisations to host their own models outside the datacentre
- What if the intelligence of models reaches a point where we cannot reasonably contain them, or they become more trustworthy than the people tasked to do so?

Whether any of these are actually realistic is probably a matter of opinion at this stage, but there is a lot that could change the way that trust boundaries are established around AI. Building an MCP server for NCrunch was clearly a sensible choice, because people wanted it immediately and they wanted it badly. Building things based on speculation about the technology or the standards around it is harder to justify.

Probably the safest choice would be to just add Linux support. It's just hard, so it's not done yet :)

I'm unfamiliar with the architecture you've described (with part of Rider on the host, and part in the container). Is the containerised part of it just the AI? Or is part of the Rider backend in there too? Right now we integrate with both the Rider frontend and backend, and IPC between them and the NCrunch engine. It's all rather involved, but I expect that if we put a split between those processes, stuff gets ... hard.

Something I have learned on this project is that it's generally better not to do things halfway. When people pay for a license, they expect a degree of polish and reliability. Sometimes a bit of duct-tape can be understandable, but this kind of data piping might be hard to justify.

I appreciate your effort in trying to find a solution though :)