Hi Paul,

Thanks for posting! I apologise for moving your message into its own thread, as the previous one was becoming a catch-all for all problems related to Microsoft.AspNet.TestHost and most of the information in that thread is badly out of date. .NET Core and NCrunch's integration with it have changed considerably over the last year.

If I understand your request, the problem you are experiencing is a performance issue. Because you are using the Microsoft.AspNet.TestHost library, you need to keep the CopyReferencedAssembliesToWorkspace setting enabled to allow this library to function and run your tests correctly. This then disables NCrunch's build optimisations and causes greatly elevated build times and frustration.

Unfortunately, I can't offer you a solution to this problem beyond that which you've likely already considered (i.e. avoiding the library or keeping the setting enabled). One of the biggest challenges in implementing NCrunch has been in working around the limitations of Microsoft's build system. The entirety of MSBuild and many of its associated toolsets are reliant on build operations being chained together to produce a combined set of output binaries, which are collocated in the test/runtime execution directory. Naturally, this is a slow process as even the smallest change to a project results in an entire chain of projects needing to be rebuilt.

With considerable effort, under NCrunch we are able to separate these projects out into workspaces and build them independently, then wire their outputs together to artificially construct test environments. Not all toolsets can work with this system. If libraries expect output binaries to be collocated, they can fail in unexpected ways when used under NCrunch. Over the years we've managed to identify and cater for many of the more common scenarios. Those that we haven't been able to produce workarounds for, we've introduced warnings to let people know that we cannot support them without the CopyReferencedAssembliesToWorkspace setting, which essentially produces an artificial build chain to fool code into thinking the projects are being built together.

The Microsoft.AspNet.TestHost library is particularly troublesome in this area because it makes use of a very targeted kind of platform level reflection that requires the existence of full dependency data for all relevant projects inside the build output directory. This dependency data can only be reliably constructed by the .NET Core platform's build system, which naturally behaves quite differently when the projects are not being built in a chain. So the entire platform has essentially been engineered against us here.

I write this to help you to understand that we do not technically consider this to be a defect within NCrunch. It is a platform-level limitation that at this stage we cannot feasibly work around. I suggest experimenting with the CopyReferencedAssembliesToWorkspace setting as it may not be necessary to have this enabled for all the projects in your solution.

Unfortunately, if you have this setting off for the rest of your projects, there probably aren't any further switches you can throw that will change this behaviour.



The problems mentioned on this thread were different in nature to the one you're experiencing. Although they all came back to the .deps files, they instead revolved around the Microsoft.AspNet.TestHost package not working at all, with no configuration options available to make it work. The problem you're experiencing is an extension of this, where the package does work, but the steps we needed to take it get it working make it slow in your environment.



I'm sorry to hear that. If I could offer you a solution to this, I honestly would. .NET Core has been a multi-year nightmare for everyone in the tools space. Maybe more options will become available as the platform continues to mature.