Hi,

It's hard for me to give you a straight answer on this without knowing more about your setup, but I can give more details about how the cross-process coverage works so that you can target your expectations :)

When NCrunch starts to execute tests in its task runner, it sets an environment variable containing an ID. This ID is then used to identify a chunk of shared memory that is allocated by the task runner.

Because child processes always inherit environment variables from their host process under Windows, any process created by the task runner (regardless of when or how it is created) will inherit the environment variable containing the ID.

If the child process contains code that has been instrumented by NCrunch (i.e. you're running NCrunch-generated assemblies inside this process), the instrumentation will kick in on the first line of executed code and will load the shared memory using the ID inherited by the child process. Code coverage can then be stored in the shared memory where it can be retrieved by the host task runner process at the end of each test run.

My understanding is that ASP.NET Core assemblies need to be built using the either the legacy project.json system or the new MSBuild system released with VS2017. In either case, they cannot be built without special handling by NCrunch (which doesn't yet exist). Because NCrunch can't yet build these projects, it also can't instrument them. Without instrumentation, there is no way to extract code coverage for the projects. So I expect that you'll probably be unable to use this system to get code coverage for ASP.NET Core, but it should be possible to get it for HTTP tests running classic .NET assemblies.