We have a large solution, and one particular project that seems to cause problems. This project ("Woti.Xift.Core") contains many common types, and so is taken as a dependency (directly or indirectly) by most other projects in the solution. It seems that whenever this project is modified, the tests that depend on it fail, throwing a System.IO.FileLoadException. Here is a representative stack trace:



The only way to resolve this is to do something that forces a rebuild and reload of Woti.Xift.Core, e.g. restart the NCrunch engine, reload and rebuild Woti.Xift.Core, etc. This is really annoying, as either one of these options essentially requires a rebuild of every single project.

This error only occurs in the context of running tests in NCrunch, and no where else in our system.

A little background: we use AOP (method intercepters) using Autofac, which in turn uses Castle.DynamicProxy. Autofac, at runtime, creates a proxy for our intercepted object, calls the interception logic, then invokes the actual method on our actual object. It's at this point where the failure seems to happen.

My best guess as to what's going on is that there's some sort of conflict as to which version of the Core assembly should be used. I can confirm that the above test project references both Core, as well as many dependencies that themselves reference Core. Here's a mock-up of the dependency graph (sorry, whitespace isn't being preserved, so it might not be as clear as I'd like).

Test Project ---> Core
|
---->web app project -----> "Infrastructure" project -----> Autofac
| |
| ------> Castle.Core
| |
| ------> Core
|
-------> X ------> Core
|
-------> Y -------> Z ------->Core

I'm looking for any solution available to make this problem go away.

Sorry for the delay in responding to this.

Yes, we definitely do auto-increment our versions on build. I didn't try disabling this, as it's done through an AssemblyVersionAttribute in a shared AssemblyInfo.cs, and would affect every project in our solution. And I doubt this is the sort of scenario that would cause us to change that.

We have many, many projects, so I didn't confirm that "prevent signing of assembly" isn't enabled for any projects, but I think it's safe to assume that we wouldn't have seen any reason to enable it.

Adding the Core project as implicit dependency did seem to eliminate this problem...in regard to Core. But I'm now intermittently getting this problem with other assemblies. I had wondered why Core was the only assembly displaying this problem, but maybe it was just the FIRST one blocking tests, since it's the one that is most depended upon by other assemblies.

It would be rather annoying if this leads to having to progressively add more and more assemblies as implicit dependencies as they pop up (due to the auto-incrementing of versions?). Given all this, is there another better solution that might be used?