Is there any option to disable the "workspaces behavior" of NCrunch (the copying/building/testing of source code in isolated folders)? I understand the workspaces probably help with build/test performance but I struggle when csproj's has any interesting customization. These projects that fail in NCrunch work under VS2017's Live Unit Testing because Live Unit Testing simply builds and tests the project and code as is.
So, I'm wondering if there is some set of configuration I can use on these projects that fail in NCrunch but work in Live Unit Testing. I much prefer NCrunch over Live Unit Testing... when I can get NCrunch to work.
Remco NCrunch Developer
#11372
17 Oct 2017 01:07 UTC
Hi, thanks for posting.
Unfortunately, the workspace behaviour is hard-built into the engine itself and cannot be disabled. Often people ask why this is the case. The reason is that it is impossible for NCrunch to reliably deliver on most of its features without using workspacing. NCrunch is a pre-build tool, in the sense that it works directly from your source code, not from compiled binaries. Its background nature means that it cannot safely share your foreground codebase with tools like Visual Studio, because there is simply too much interference from the IDE and other processes to allow it to perform work in this area. NCrunch also heavily manipulates the build system, output artifacts and runtime environment in a manner that does not play well with other tools, especially those that also attempt to take ownership of these areas and are changing on an almost monthly basis.
True and unconstrained background execution without some form of workspacing is unfortunately impossible. If it were feasible for me to provide a build of NCrunch without workspacing, I am fairly certain it is not a product you would consider worth using.
If you have customisations that prevent your projects from being built in the workspace, I recommend disabling these using MSBuild conditions (i.e. Condition="'$(NCrunch)' != '1'). NCrunch does also have a range of configuration options that are worth learning in detail as they can help with projects that don't like workspacing.
Unfortunately, the workspace behaviour is hard-built into the engine itself and cannot be disabled. Often people ask why this is the case. The reason is that it is impossible for NCrunch to reliably deliver on most of its features without using workspacing. NCrunch is a pre-build tool, in the sense that it works directly from your source code, not from compiled binaries. Its background nature means that it cannot safely share your foreground codebase with tools like Visual Studio, because there is simply too much interference from the IDE and other processes to allow it to perform work in this area. NCrunch also heavily manipulates the build system, output artifacts and runtime environment in a manner that does not play well with other tools, especially those that also attempt to take ownership of these areas and are changing on an almost monthly basis.
True and unconstrained background execution without some form of workspacing is unfortunately impossible. If it were feasible for me to provide a build of NCrunch without workspacing, I am fairly certain it is not a product you would consider worth using.
If you have customisations that prevent your projects from being built in the workspace, I recommend disabling these using MSBuild conditions (i.e. Condition="'$(NCrunch)' != '1'). NCrunch does also have a range of configuration options that are worth learning in detail as they can help with projects that don't like workspacing.
Edited 17 Oct 2017 01:08 UTC
Post a reply
Log in to reply.