nCrunch dosn't see new files matching pattern in "Additional files to include"

Hi,

In "Additional files to include" I have a pattern with wildcard, ie: "Tests\TestData\*.xml". After modifying one of .xml files in this folder, nCrunch will see this, copy modified file into workspace and run impacted tests. But, if I add a new *.xml file into this folder, nCrunch doesn't react. The only way (that I've found) to run tests with this new file is to run "Reload and rebuild selected component", which is time consuming and cumbersome.

Hi,

Yes, this is a known limitation. If you're working in a situation where files are being frequently added, I would recommend including them in the project file instead, if at all possible.

Hi Remco,

is this limitation due to architecture/technical problems or performance issues? If only performance, than maybe You could add some switch in preferences to enable such behavior for those who needs it? Adding those files into project file is also cumbersome, because there are many of them and adding new file into csproj is several clicks (ie. enable 'show all files', find folder in directory structure, open context menu and click 'include in project', disable 'show all files').

Hi Marqus,

It's all 3.

I'm going to be completely honest with you here. This part of the product (synchronisation with file changes) was written many years ago, and it took a good long while to have it working as reliably as it is now. Synchronisation with file changes is one of those things that appears very simple (i.e. just hook up a FileSystemWatcher), but actually it's fiendishly hard to do under VS. We need to watch just the right things but not the wrong ones, as otherwise we end up with dependencies on derived files, build loops, and really crazy stuff. VS itself does some really unexpected things with the file system while you have projects open, and the files we're working with aren't strictly just the files on disk, but rather they are a combination of these files and the files held open within VS (which is in a completely different memory space).

So I guess what I'm trying to say is that this is complicated. I would like to construct a solid response about whether this can be feasibly fixed or not, but the truth is that this isn't something that can be easily answered without significant investment of time spent investigating and understanding every angle. If we get something wrong, we could end up putting the entire userbase in cryptic build loops or performance issues for a whole release cycle. As such, it's very much my preference to find an acceptable solution for you that doesn't involve adding a greedy file includer. I would prefer to keep this as a known limitation until an opportunity presents itself to safely and efficiently resolve it.

Hi Remco,

Thank you for answer. I guess I will have to live with this :)