Welcome Guest! To enable all features please Login or Register.

Notification

Icon
Error

NCrunch Warnings about copying assemblies to build output directory
jepthy
#1 Posted : Friday, February 18, 2022 4:55:03 PM(UTC)
Rank: Newbie

Groups: Registered
Joined: 12/28/2021(UTC)
Posts: 2
Location: United States of America

I am using Visual Studio 2022 Community Edition, and NCrunch 4.11.0.2. I am building a WebApi project using .NET 6, and using MSTest Projects for my unit and integration tests.
I am finding that in Visual Studio's NCrunch Test Window, all of my Test Projects give the warning that the project requires referenced assemblies to be copied to the build output directory.
I found a few articles about a setting on whether to copy referenced assemblies, but this is set to false in accordance with best practices.

While I realize I can dismiss this warning, I am curious on why it is on by default. Am I doing something wrong, or do I need to change something to resolve this warning, rather than dismissing it?

The full trace output is:
The Microsoft.AspNetCore.TestHost package contains code that extracts dependency data from the .deps files of user projects in its environment. NCrunch is unable to safely provide this dependency data without copying referenced assemblies to the build output directory. This will have an impact on the performance of NCrunch, as extra work must be done to rebuild this project every time one of its dependencies changes. You may also need to turn on the 'Copy referenced assemblies to workspace' NCrunch project-level configuration setting for other projects in this solution to resolve deeper dependency issues related to the use of this package. 'Copy referenced assemblies to workspace' has been implicitly enabled for this project.
Remco
#2 Posted : Saturday, February 19, 2022 12:03:42 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 6,667

Thanks: 877 times
Was thanked: 1191 time(s) in 1111 post(s)
Hi, thanks for sharing this.

The more detailed explanation to this is rooted within the architecture of the .NET platform and certain design decisions that have been made within NCrunch. The name of the configuration setting involved ('Copy referenced assemblies to workspace') is actually not ideal, but we don't have an acceptable way to change the name of the setting without impacting everyone, and so it persists.

When Visual Studio (or MSBuild) builds a project, it constructs a dependency tree of the project and all other projects it depends on. It then builds the entire tree, starting from the bottom. This effectively makes it impossible for you to build only the project you want to build without all its dependencies being passed through the system. MSBuild does have some level of optimisation to avoid rebuilding projects that have just been built, but this is very limited and there is still a considerable performance cost. So if you were to make a surgical change to a project at the top of a large dependency tree, you can expect the build to take quite a while even if you only changed a single line of code. Naturally, this has serious implications for a performance critical test runner like NCrunch.

So to get around this, we pull projects out of the solution and rewire their dependencies so that they are built in isolation. This has major performance advantages and often makes the difference between being able to return test results in a few short seconds as opposed to one minute plus. Unfortunately, we break a number of abstractions when we do this, and it only works if we avoid copying the DLLs of referenced projects into the build output directory of the project.

Why can't we copy DLLs of referenced projects into the build output directory? This is due mostly to file locking issues. When we have open test environments using the temporary workspace, they hold locks on the DLLs in the process. This stops us from updating and re-using the workspace easily when other changes are made to the codebase. More locked DLLs in the workspace means less flexibility for the engine which means higher disk consumption, longer spinup times and worse performance.

So basically, we have a system in place where solutions with a simple interproject dependency structure can be handled very efficiently by NCrunch with minimal resource consumption and hopefully little configuration required. Unfortunately, this starts to break down when additional toolsets become involved that require reference DLLs to coexist in the build output directory with the primary output file. Basically, if you were to write any code in your solution that tries to manage the location of reference DLLs by itself and will only work if they are adjacent to one of your other assemblies, then NCrunch won't work with this code unless 'Copy referenced assemblies to workspace' is turned on. In years gone by we mostly hit this problem with IOC containers and the like, but now we also have Microsoft.AspNetCore.TestHost, which micro-manages dependencies obsessively and took a huge effort from us to even have it work at all.

At the time NCrunch was first introduced, the concept of a solution being a buildable unit wasn't really as solid as it is now. Back then, pulling projects out of the solution and building them in isolation didn't upset too many toolsets as the build system was generally simpler and less extensible. Now, someone can just grab a Nuget package that completely restructures the whole build system in a way that we just can't efficiently organise NCrunch around. When packages or toolsets that do this become really popular, we make NCrunch detect them and turn the setting on to save people the trouble and confusion .. but sadly the performance benefits of the optimised system move out of reach.
jepthy
#3 Posted : Monday, February 21, 2022 3:36:33 PM(UTC)
Rank: Newbie

Groups: Registered
Joined: 12/28/2021(UTC)
Posts: 2
Location: United States of America

That makes a lot of sense, thank you for the detailed explanation. Sounds like the best course of action would be to just ignore this warning then?
Remco
#4 Posted : Monday, February 21, 2022 10:57:53 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 6,667

Thanks: 877 times
Was thanked: 1191 time(s) in 1111 post(s)
jepthy;16005 wrote:
That makes a lot of sense, thank you for the detailed explanation. Sounds like the best course of action would be to just ignore this warning then?


Yes, just ignore it :)
pineleaf
#5 Posted : Tuesday, November 1, 2022 5:47:00 AM(UTC)
Rank: Newbie

Groups: Registered
Joined: 11/1/2022(UTC)
Posts: 1
Location: Australia

Hi I am hitting the exact same issue as above - only issue is that when I "Hide Selected Warning" then reload/rebuild it continues to have a status of not built.

I don't see any UI element to ignore the warning - is hiding different to hiding?


Remco
#6 Posted : Tuesday, November 1, 2022 6:21:52 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 6,667

Thanks: 877 times
Was thanked: 1191 time(s) in 1111 post(s)
pineleaf;16329 wrote:
Hi I am hitting the exact same issue as above - only issue is that when I "Hide Selected Warning" then reload/rebuild it continues to have a status of not built.


Does turning on/off the 'Show unexecuted tests' filter option make the project disappear? Do related tests still run? I'm wondering if this is a build issue or a UI glitch.


pineleaf;16329 wrote:

I don't see any UI element to ignore the warning - is hiding different to hiding?


For the purposes of this warning, hiding and ignoring are both the same thing.
Users browsing this topic
Guest
Forum Jump  
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.

YAF | YAF © 2003-2011, Yet Another Forum.NET
This page was generated in 0.062 seconds.
Trial NCrunch
Take NCrunch for a spin
Do your fingers a favour and supercharge your testing workflow
Free Download