Build errors for Aspire when building under NCrunch

[Erwinvandervalk]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

NCrunch is an amazing test runner. Unfortunately, it appears it doesn't work with aspire and the owner of NCrunch looked and it's not (currently) possible to make aspire working under NCrunch.

There is an excellent description of the problem here:
https://forum.ncrunch.net/Default.aspx?g=posts&t=3541

Below is a detailed message (part of this issue description in the ncrunch forum) from Remco:

The root issue is that this particular toolset treats the entire solution as a buildable unit, and projects cannot be separated from the solution and built independently. This isn't a new thing - MS have moved towards such an approach quite a lot over the last decade, but in most cases I've managed to find workarounds to allow NCrunch to operate regardless.

The features NCrunch provide work by copying projects out into workspaces and building them independently from each other. This has a range of advantages, particularly around performance. It takes a lot longer to rebuild a whole solution than it does to build a single project in the context of a small code change, so it makes sense to do this when you want test results quickly. It was a design introduced back in 2009 when the MSBuild system was designed in a way that made this sort of thing much easier.

Aspire contains a range of build steps that generate reference .cs files at load/build time which point to the .csproj files being referenced by the project involved. These files contain hard coded absolute paths that get passed into the compiler and are used at run time to find the projects involved. This means that the compiled code contains absolute path references to the uncompiled source/projects used to generate it, making it essentially impossible to separate them.

I've managed to work around the above by using build steps to forcefully delete the generated .cs files, then adding custom code that uses NCrunch environment information to locate the required .csproj files in the NCrunch workspaces, effectively patching the hole and allowing the projects to build correctly.

Unfortunately, it all fell down when the tests started to run. Aspire runs the code under test by executing the API Service .EXE directly inside a new process. As such, it's effectively building its own testing infrastructure inside of the test run, which is dependent on the packaging of the projects involved as would be required for a fully deployed environment. NCrunch deliberately disables these packaging steps because they don't work correctly in its environment (they likewise expect the solution to be built as a unit), and normally they aren't required for running tests.

So this is kind of a brick wall. Even if there is a way to get the packaging steps to work correctly in NCrunch's environment, it's impossible to make any guarantees around the behaviour of Aspire's sub-environment under NCrunch, particularly in regards to lifecycle management, parallel execution, process stability, etc.

Sorry, we can't support this toolset under NCrunch.

I wonder if there would be some thing that could be changed in how Aspire builds that makes it somehow possible for NCrunch to work.

Expected Behavior

No response

Steps To Reproduce

No response

Exceptions (if any)

No response

.NET Version info

No response

Anything else?

No response

[davidfowl]

The NCrunch engineers would need to come on here and we could figure out a solution.