I have a Web application written in C# (server) and Typescript (client). I use a single .csproj in this instance.

I've excluded *.js and *.ts files in my NCrunch settings but whenever I edit/save Typescript files, NCrunch builds/tests the C# code.

Is there a way to determine what triggers the NCrunch build?

I agree that it's likely some other tooling changing something and triggering the build. I'll see if I can put together a sample project that illustrates the problem.

Of course, this is totally your fault. If you hadn't made it so easy run tests I wouldn't have written so many and this wouldn't be a problem. :)

OK, I figured out the issue.

My folder structure for Typscript is:

\myproject\js\apps\...

The output folder for Typescript is:

\myproject\js\bin\

This is where the outputs for Typescript go (bundle.js and bundle.js.map).

Deleting a file in the \myproject\js\bin folder triggers an NCrunch build.

Could it be my choice of folder name here (bin)?

P.S. Renamed the bin folder to "out". Had to change a bunch of references in the project and build scripts but afterwards, things work as expected. Editing *.ts files does not trigger an NCrunch build/test cycle.

It looks like something isn't right with the files you have included in the workspace. You'll want to avoid including derived files in the workspace where possible. Check for broad use of the 'Additional files to include' setting.

From memory, the 'Files excluded from auto-build' setting was intended to exclude file edits from the auto build feature. If files are physically removed from the project, this is considered to be a project change rather than a file change (as it impacts the project XML). When a project is changed, NCrunch must rebuild the project regardless of how you are using the setting.

There is a way we can do this :)

Where the files are declared inside your Build XML, for example:

<ItemGroup>
<None Include="bundle.js" />
<None Include="bundle.js.map" />
</ItemGroup>

You can exclude them for NCrunch with a condition:

<ItemGroup>
<None Include="bundle.js" Condition="'$(NCrunch)' != '1'" />
<None Include="bundle.js.map" Condition="'$(NCrunch)' != '1'" />
</ItemGroup>

Or alternatively:

<ItemGroup Condition="'$(NCrunch)' != '1'">
<None Include="bundle.js" />
<None Include="bundle.js.map" />
</ItemGroup>

The files will then be detected by the IDE and VS publish, but excluded from NCrunch.

Are you making use of the 'Additional files to include' setting at all? Do you know if there are any other references to this file through your project structure?

A good way to test whether NCrunch is still including the file in its workspace is to break this project so it won't build (or copy/produce the .js files in your out dir), then reset the engine. You can then inspect the workspace by going through the Advanced->Browse to workspace option in the Tests Window. Is the file shown in the workspace? If so, that means NCrunch will likely have identified it as a dependency and copied it. If not, there may be something else watching this file that is triggering NCrunch.

Thanks for the sample project.

In this case, NCrunch's build is being triggered by the derived files from the typescript auto generation. When you hit save, typescript is automatically running code over the .ts files to generate outputs. Because these outputs are included in your project file, NCrunch is watching them for changes and will trigger when they are modified on disk.

I was able to suppress this behaviour with the following modifications made to the project file:

<ItemGroup>
<Content Include="Content\nancy-logo.png" />
<None Condition="'$(NCrunch)' != '1'" Include="Content\out\bundle.js" />
<None Condition="'$(NCrunch)' != '1'" Include="Content\out\vendor.css" />
<None Condition="'$(NCrunch)' != '1'" Include="Content\out\vendor.js" />
<Content Include="Web.config" />
</ItemGroup>

Edit: I'd like to add that this does actually look like a bug in NCrunch. The 'Files excluded from auto build' is only being applied to changes that come from the IDE, not from the file system. It seems like it should work for both. I've noted this down for review.