Hi, thanks for sharing this issue.

The first thing I'd try is turning off the 'Instrument output assembly' setting for this project. C++ projects aren't properly supported for NCrunch instrumentation anyway, so this isn't likely to have any downside .. and it will reduce the amount of processing NCrunch does on the assembly.

Something else worth doing would be to set your 'Log Verbosity' to 'Detailed', then examine the build log inside the Processing Queue for the project's build task. The NCrunch build log can sometimes give some useful information on timings. If turning off the instrumentation doesn't have any impact on the build time, then the build log may give us a clue as to where the bottleneck is.

This makes sense. Copying 38,000 files into each workspace will make a difference in build time.

I can suggest a solution to this, although it isn't a tidy one ... basically it involves referencing the library files using absolute file paths and removing them from the 'Additional files to include'. In this way they'll be referenced from your original solution directory instead of the workspace they'd otherwise need to be copied to. This is a bit messy because it does break workspace isolation - although for read-only libraries this is probably OK. If you're reluctant to warp your project with the absolute paths (which is messy for VCS systems and fresh checkouts), you may be able to get away with using an environment variable that can be specified on the machine to point to where the files need to be.

Sorry, I often have my head stuck in C# land :)

It may be enough to simply adjust the library search paths. Most likely if you are including the headers using #include, then you'll have a relative search path set in the project pointing at the directory of the header files for the boost libraries. Changing this to an absolute file path would make NCrunch use the boost libraries that sit in your foreground solution, instead of trying to search relatively from the workspace and needing to have all the files copied with the project.

Interesting ... It must be the case that MSBuild is automatically resolving these dependencies during the NCrunch load, then reporting them to NCrunch as being files inside the project. If this is indeed the case, it may be possible to work around this by hiding them from the NCrunch load.

Inside the project file, try adding a build condition to the declaration for the Additional Include Directory. For example:

<AdditionalIncludeDirectories Condition="$(NCrunch) != '1'">C:\Program Files %28x86%29\Boost\boost_1_51_0</AdditionalIncludeDirectories>

Yes. Sorry ... it's likely this wouldn't have actually worked, even if it worked ... if that makes any sense :/

We're running out of options here. The big issue is that there isn't a way for NCrunch to separate the included files from other source files in your solution - MSBuild is simply combining them and returning a unified result set. This means that either the files get copied, or they can't be referenced at all and the build will completely fail.

I think the best option may to be look at ways in which we can exclude this particular project/assembly from NCrunch itself, and use NCrunch for the rest of your solution. Since NCrunch won't support code coverage over a C++ project anyway, there is probably little value in having it as part of the NCrunch build tree.

The way to do this is by building the output assembly from the project, then referencing the built assembly directly (from all depending projects) instead of the C++ project. This will likely make a mess of your build sequence, so the best way to handle this would be to make the references conditional on NCrunch being resident so that the <AssemblyReference> is used for NCrunch, and the <ProjectReference> is used for Visual Studio. This will let you use NCrunch without making a mess of your VS build. The only way you can do this is by modifying the project files manually and adjusting the references.

So the following:

<ItemGroup>
<ProjectReference Include="..\MyCppProject\MyCppProject.vcxproj">
...
</ProjectReference>
</ItemGroup>

Would become:

<ItemGroup>
<ProjectReference Include="..\MyCppProject\MyCppProject.vcxproj" Condition="$(NCrunch) != '1'">
...
</ProjectReference>
</ItemGroup>
<ItemGroup>
<Reference Include="..\MyCppProject\Bin\Debug\MyCppProject.dll" Condition="$(NCrunch) == '1' />
</ItemGroup>


When this change has been made, you'll need to do a rebuild of the C++ project in VS every time you make changes to it. This is because NCrunch will be hooked up to the output of this project, so it won't detect the change until you rebuild manually.

You'll need to turn on the 'Ignore this project completely' NCrunch project-level configuration setting for the C++ project, otherwise it'll still try to build it and consume valuable resources.

NCrunch may give you a warning about a 'lost reference' - just ignore this.

Great suggestion, thanks. I completely forgot about how VS would interpret it. I hope all is well now.