Strange FileNotFoundException

Hi Remco,

so, I got a new project where I can really do TDD and finally decided to buy NCrunch. It was just too much pain to perform TDD without it.

But now I got a rather strange issue.

I have the following setup:

Project under test:
WPF application .NET 3.5
References the Ninject NuGet package

Test project:
.NET 4
References the Ninject NuGet package

I can run the tests just fine in Resharpers runner.
But in NCrunch the test that really uses Ninject fails with:

*** Failures ***

Exception
System.IO.FileNotFoundException: System.IO.FileNotFoundException : Could not load file or assembly 'Ninject, Version=3.0.0.0, Culture=neutral, PublicKeyToken=c7192dc5380945e7' or one of its dependencies. Das System kann die angegebene Datei nicht finden.
   at System.Reflection.RuntimeAssembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
   at System.Reflection.RuntimeAssembly.nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
   at System.Reflection.RuntimeAssembly.InternalLoadAssemblyName(AssemblyName assemblyRef, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection, Boolean suppressSecurityChecks)
   at System.Reflection.RuntimeAssembly.InternalLoad(String assemblyString, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection)
   at System.Activator.CreateInstance(String assemblyName, String typeName, Boolean ignoreCase, BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes, Evidence securityInfo, StackCrawlMark& stackMark)
   at System.Activator.CreateInstance(String assemblyName, String typeName)
   at System.AppDomain.CreateInstance(String assemblyName, String typeName)
   at System.AppDomain.CreateInstanceAndUnwrap(String assemblyName, String typeName)
   at System.AppDomain.CreateInstanceAndUnwrap(String assemblyName, String typeName)
   at Ninject.Modules.AssemblyNameRetriever.GetAssemblyNames(IEnumerable`1 filenames, Predicate`1 filter) in c:\Projects\Ninject\ninject\src\Ninject\Modules\AssemblyNameRetriever.cs:line 50#0
   at Ninject.Extensions.Conventions.BindingBuilder.AssemblyFinder.FindAssemblies(IEnumerable`1 assemblies, Predicate`1 filter) in c:\Projects\Ninject\ninject.extensions.conventions\src\Ninject.Extensions.Conventions\BindingBuilder\AssemblyFinder.cs:line 61#1
   at Ninject.Extensions.Conventions.BindingBuilder.ConventionSyntax.From(IEnumerable`1 assemblies) in c:\Projects\Ninject\ninject.extensions.conventions\src\Ninject.Extensions.Conventions\BindingBuilder\ConventionSyntax.From.cs:line 115#2
   at Ninject.Extensions.Conventions.BindingBuilder.ConventionSyntax.FromAssembliesMatching(String[] patterns) in c:\Projects\Ninject\ninject.extensions.conventions\src\Ninject.Extensions.Conventions\BindingBuilder\ConventionSyntax.From.cs:line 157#3
   at DeliveryConfirmation.TouchTerminal.CompositionRoot.<Execute>b__0(IFromSyntax x) in C:\Data\Projects\TouchTerminal\Application\DeliveryConfirmation.TouchTerminal\CompositionRoot.cs:line 26#4
   at Ninject.Extensions.Conventions.ExtensionsForIKernel.Bind(IBindingRoot kernel, Action`1 configure) in c:\Projects\Ninject\ninject.extensions.conventions\src\Ninject.Extensions.Conventions\Extensions\ExtensionsForIKernel.cs:line 59#5
   at DeliveryConfirmation.TouchTerminal.CompositionRoot.Execute() in C:\Data\Projects\TouchTerminal\Application\DeliveryConfirmation.TouchTerminal\CompositionRoot.cs:line 24#6
   at DeliveryConfirmation.TouchTerminal.CompositionRoot.Execute[T]() in C:\Data\Projects\TouchTerminal\Application\DeliveryConfirmation.TouchTerminal\CompositionRoot.cs:line 52#7
   at DeliveryConfirmation.TouchTerminal.Tests.CompositionRootTest.General.CompositionRootRegistersOneActiveCollectionConductor() in C:\Data\Projects\TouchTerminal\Application\DeliveryConfirmation.TouchTerminal.Tests\CompositionRootTest\General.cs:line 11#8

I checked the working directory of NCrunch (c:\Users\daniel.hilgarth\AppData\Local\NCrunch\).
The file Ninject.dll exists multiple times. Version is always 3.0.0.0, culture and public key token are also always the same as in the stack trace, but:
The runtime - as reported by ILSpy - is sometimes .NET 4.0 and sometimes .NET 2.0.
Because one of the projects is .NET 4 and one is .NET 3.5 this kinda makes sense, but it also seems to somehow confuse NCrunch.
However, this can't be the only reason, because I have the same scenario with Caliburn.Micro. It is also referenced in both projects.


Any ideas?

Hi Daniel -

Ninject is well known for its dynamic resolution of referenced assemblies, which can be a bit of a nightmare for a tool such as NCrunch. The first thing I would try in this situation is the Preload Assembly References configuration setting. Setting this to TRUE for all projects in your solution will allow NCrunch to enforce greater control over which referenced assemblies are loaded, which may have a chance at resolving this problem.

Most people that make use of Ninject also need to enable the Copy referenced assemblies to workspace configuration setting, as Ninject assumes that all referenced assemblies exist in the same output directory as the primary assembly.

Hi Remco,

the first setting didn't change anything but setting "Copy referenced assemblies to workspace" to TRUE worked, thanks!

However, I wonder, what the actual problem was. If you study the stack trace closely you notice that the exception originated from within Ninject, meaning it already has to have been loaded.

With my limited knowledge of Ninject, I can only guess that for some reason this framework wants to take responsibility for loading assemblies into the application domain manually. In a certain perspective of IoC, this would make sense, as the dependencies of an application may not be under the direct control of the application itself (and therefore need to be loaded dynamically), although I agree that when a framework can't find itself, something definitely doesn't look right!