Submitting the form at https://www.ncrunch.net/support/contact results in a 'could not find the page' error.

It worked now I try with garbage parameters and no zip file.

My zip file is approx 18Mb - could that be the issue?

I just stripped out the obj and bin folders. Bit more setup cos private nuget packages but its all there. Email me if you have any issues when you get around to taking a look.

Thanks.

Thanks!

As soon as coffee and the required increase in brain power permits :D

Thanks for sending this through.

Could you quickly confirm for me if turning on the 'Copy referenced assemblies to workspace' setting for the projects involved makes any difference in regards to this error?

Thanks for sending through the larger sample.

The problem here is again caused by interoperability between PostSharp and NCrunch. In this situation, there is an aspect in one of your projects that triggers the creation of attribute constructor code which PostSharp executes during the build of subsequent projects. Because NCrunch also instruments code when it builds your projects, the aspect itself is instrumented and has references to NCrunch.TestRuntime.DotNetCore.dll. When NCrunch processes your tests at runtime, it can supply the test environment with the binding information necessary to find this file. However, PostSharp needs the file at build time (which we never expected, since normally user code is not run during build time).

Under .NET Framework, this wouldn't be a problem as the NCrunch.TestRuntime binary is loaded in the GAC where everything can find it. Unfortunately, .NET Core does not rely on this search path.

If more users encounter this situation we might be able to add an integration point in NCrunch to properly solve it, but right now this looks quite situational, so the focus is on finding a suitable workaround. The plan is to make sure that the NCrunch.TestRuntime.DotNetCore file exists in the build output directory of the project declaring the aspects.

To do this, we use a pre-build step to copy the file from a fixed location and place it in the necessary place when NCrunch is processing the project containing the aspects. I managed to get this working in the aspect project you provided by adding the following to the .csproj:

<Target Name="PreBuild" BeforeTargets="PreBuildEvent" Condition="'$(NCrunch)' == '1'">
<Exec Command="md $(ProjectDir)bin\debug\net5.0&#xD;&#xA;copy /Y c:\PathToAssembly\nCrunch.TestRuntime.DotNetCore.dll $(ProjectDir)bin\debug\net5.0" />
</Target>

For this code to work, you'll need to grab the nCrunch.TestRuntime.DotNetCore.dll file from your NCrunch installation directory (usually something like C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\Common7\IDE\Extensions\Remco Software\NCrunch for Visual Studio 2019), then copy this to a known location (i.e. 'C:\PathToAssembly').

Turning off instrumentation for the whole solution also works - but then that sort of removes the second primary function of NCrunch - the code coverage dots.

So the work around is working but it is not without strangeness...

1. Changing the project file contents was not immediately reflected in ncrunch test window. Something is being cached somewhere? I tried reloading project and reloading whole solution too.
2. Editing the project file occasionally resulted in a hung, crashed, restarting automatically.

These is the strange one:

3. The projects EntityComponentSystem and EntityComponentSystem.Tests both used to fail before the workaround. EntityComponentSystem ALSO contains aspects. NCrunch compiled these 2 projects (and others dependent on the same aspects) correctly WITHOUT the pre-build event.
4. When I turned off the pre-build events in NCrunch (either individual project or whole solution) Framework.Contracts.Tests continued to compile correctly??!!!???

So, right now, I can make progress but given 3 and 4, I'm not confident it won't suddenly bork again :( If it does, I'll capture the circumstances and let you know.

That all makes sense.

Just in case you missed it, the other workaround is to remove all the aspects from the solution and put them in a nuget package. You then only need the workaround for solutions with the aspects themselves and the main solution will consume the aspects just fine.

VS bugs? Say it isn't so! :D

For 1 I did try various things like resetting the NCrunch engine and outright deleting the ncrunch workspace folder to see if I got a reaction but I see what you mean.

3/4 is odd but I get what you mean about 'its in the search path'.

TLDR, as long as one of the leaf dependencies is fixed with the workaround, it looks like I am good to go.

Thanks for all the help and the immediate response (especially given the time zone difference and having to occasionally stop hobbits from chewing through your broadband line).