Hi,

I can't think of any known issue that would cause this kind of behaviour - nor any change in upgrade that would trigger it. NCrunch itself has no special handling for NCrunch.Framework - this DLL is simply another referenced library and the behaviours it unlocks work entirely through string matching off attribute names (you can declare the attributes within your own code and they will also work).

NCrunch.Framework rarely sees changes and the updates via Nuget are usually just a version number adjustment. I think that there is something else happening with your code that is causing this. Do you have any code inside your application domain that adds event handlers onto the AppDomain's AssemblyResolve property? If you manage to isolate the problem in a code sample, please feel free to send it to me via the (- BROKEN LINK -)contact form [/url].

Thanks for the repro. I've taken it for a spin and may be able to give some answers on this. The difference in behaviour you've observed between versions is caused by the presence of NCrunch.Framework.dll in the GAC. Where the version of NCrunch.Framework.dll referenced by the project is consistent with the one installed in the GAC, the CLR will automatically find the GAC assembly prior to invoking the assemblyresolver. Where NCrunch.Framework.dll is not present in the GAC, or the GAC version is different to the one referenced in the project (which may be handled using Nuget), the CLR won't find it immediately and will attempt to resolve it using the assemblyresolver. Naturally, the assemblyresolver requires the assembly itself in order to perform the resolution ... and so you get a stack overflow.

In the code sample you've given me, there is a defect in the PathPointsAtFile method. This method is calling Path.GetFileNameWithoutExtension on the wrong parameter (should be against fileName instead of path). This is causing in inconsistent comparison and causing the loader to always fail. On fixing this problem, the code started passing for me where the GAC version was consistent.

NCrunch itself ships with NCrunch.Framework and will install this in the GAC for convenience. It's a bit of a legacy action as most people these days will reference the assembly using Nuget. In this case, I don't think the GAC dependency in your code was intentional .. so it isn't a good idea to rely on NCrunch.Framework inside an assembly resolver. There are a couple of options available for you in fixing this problem:

1. Use NCrunchEnvironment.GetAllAssemblyLocations() from outside your custom application domain. Create a 'loader' type inside the application domain and pass the results of this method call into the application domain as a string array, prior to setting up the assembly resolver.
2. Implement NCrunchEnvironment.GetAllAssemblyLocations() in your own code. This method basically just backs onto an environment variable, so you can just copy/paste this into your own source:

public static string[] GetAllAssemblyLocations()
{
var dependencies = Environment.GetEnvironmentVariable("NCrunch.AllAssemblyLocations");
if (dependencies == null)
return null;

return dependencies.Split(';');
}