Hi,

Merry Christmas, all the best to you and all the developers - thanks for a great product.

Today I stumbled on an issue however. In my existing solution, I wanted to start checking out Aspire.
So I created a solution folder, and added a new project, using the default template for ".Net Aspire Starter App". (VS2022 preview (latest update at the moment), Aspire 9.0, dotnet 8, ncrunch 5.11.0.1 - of course I can provide more details if needed)
(using all defaults)

NCrunch has a problem building two of the auto-generated projects out of the box. Maybe I need to tweak some configuration settings for these ?

The first project would be the following auto-generated MyApp.Aspire.AppHost.csproj.


In it are a regular appsettings.json and an auto-generated Program.cs


However, it turns out nCrunch cannot this project.
In the generics in Program.cs builder makes use of a design-time generated class for each referenced project, but nCrunch probably has no way of finding those classes.
I can find three generated files in **my_base_path**\MyApp.Aspire.AppHost\obj\Debug\net8.0\Aspire\references\
_AppHost.ProjectMetadata.g.cs
MyApp_Aspire_ApiService.ProjectMetadata.g.cs
MyApp_Aspire_Web.ProjectMetadata.g.cs

In the last two files I can find the classes I talked about.
Should I change something in the ncrunch project configuration to make the magic happen ?

NCrunch build output for this project says:


The second project would be the auto-generated test project. (probably for the same reason, but nCrunch does not provide build/error output for this one)

Thanks for the suggestion. I didn't try it then indeed.
I tried just now (everything dotnet 9), and have the same outcome. (ncrunch fails on the same projects, with the same output)

Thanks for sharing this issue. Can you check if the missing files are stored in the NCrunch workspace? I'm wondering if this could be as simple as just adding them to the 'Additional files to include' setting.

Try adding these missing files to the 'Additional files to include' project-level NCrunch configuration setting. I suspect they are somehow not being detected as dependencies, so they don't get copied into the workspace as they should be. It looks like these files are being created at load time when packages are restored.

Thanks for sharing the ZIP. I've reproduced the problem as you've described it.

I've spent some time trying to devise a way to get this to work. Unfortunately, I can't see a path to a solution .. not even a hacked up one.

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.