I understand that Azure projects are not officially supported by NCrunch. This problem seems to be one that, while encountered here in an Azure Functions project, could just as well occur in a non-Azure project.

Reproduction of this issue is easy. Here are the steps:

1. Create a new Visual Studio project using the built in “Azure Functions” template. (This template is listed under the “Cloud” folder in the New Project dialogue box.)
2. Build the project. No modifications necessary. It will build successfully.
3. Enable NCrunch using the default settings.
4. NCrunch gives an immediate build failure message.

The problem seems to be that if a project build happens to put the new assembly in a subdirectory of the project output directory rather than directly in the root, NCrunch will fail to find it. In the example case above, the project created by the built-in VS template for Azure Functions, will place it’s output file in a subfolder called “<project name>\bin\Debug\net461\bin” rather than directly in the root output folder (<project name>\bin\Debug\net461). NCrunch apparently does not recursively check any subfolders for the file.

I located a discussion on this issue (with the exception that NCrunch isn’t involved) in the Azure Functions Github site at: https://github.com/Azure...re-Functions/issues/441

One of the project maintainers appears to believe that their side of the issue has been addressed. This does not appear to be the case (at least from the NCrunch perspective).

Any guidance would be appreciated.

Thank you, Remco. No need to apologize.

I appreciate you taking the time to reply. I’m sure this information will be useful for other devs as they encounter these issues.

While I am disappointed that I can’t use NCrunch for my Azure projects, I’m glad to have a more clear understanding of the tool. I also appreciate that you recognize your resource limitations and define support boundaries accordingly. As a customer, I’d prefer the product be limited in capability, but solid, rather than flimsy because the author has over-committed.

My hope was that NCrunch could be my only test runner, but as I discover the limitations, it looks like more of a “right tool for the job” product. I’ll continue to use it for my “core” (clean code/hexagonal design) and I’ll revert back to a more traditional runner for my outer layer infrastructure/framework projects.

You’ve got a great product. I hope with the seeming stabilization of things with .net core 2, you’ll be able to return to more normal dev and support situation.

Hi Colin,

I'm sorry but as discussed above, this project type is not supported by NCrunch.

I.e. The path to my normal .net framework project is: \bin\Debug\net461 - this works fine in ncrunch
The path to an azure function SDK generated project is: \bin\Debug\net461\bin - it would be great if I could configure the additional bin folder.

Of course this simple change is no doubt not simple...
Cheers,
Colin