Throws exception when using Ninject.Extensions.Conventions

Hello,

NCrunch is throwing exception when trying to bind using conventions from the Ninject.Extensions.Conventions assembly. If I bind manually, then it runs fine. The R# test runner has no trouble running the tests with the code from the Conventions assembly.

Following is the exception it throws:
System.IO.FileNotFoundException : Could not load file or assembly 'Ninject, Version=3.0.0.0, Culture=neutral, PublicKeyToken=c7192dc5380945e7' or one of its dependencies. The system cannot find the file specified.

I have checked the _ncrunchreferences directory and it has all the required files but still it has problem finding the file.

My Environment:
VS 2012 Ultimate
NCrunch 1.42.0.12
Ninject 3.0.1.10 (the current version as of this post)
Ninject Conventions 3.0.0.11 (the current version as of this post)
NUnit 2.6.1


Thanks,

Imran.

Hi Imran -

I suspect this may be due to Ninject expecting the referenced assemblies to be co-located with the project's output assembly, which isn't always the case under NCrunch. There's a page in the documentation that describes this problem and various ways that you can deal with it. If this doesn't work, do let me know and we'll dig a bit deeper and perhaps try something else.


Cheers,

Remco

Hi there, I'm having the same issues and expect the correct solution to be "Copy Referenced Assemblies To Workspace" from the previously mentioned page of docs.

Those docs do have a note saying "In situations where NCrunch detects a well known framework that requires assemblies to be collocated, it will often enable the Copy referenced assemblies to workspace setting automatically."

It seems like this might be an example of such a framework? How do frameworks get added to the implied list of special cases? Do I submit a suggestion? PullRequest? something else?

As Ninject is a runtime framework, there is a high chance that other solutions exist that won't require the 'Copy referenced assemblies to workspace' setting to be enabled forcefully by the engine. Unfortunately I'm not personally familiar enough with the internals of Ninject or how it resolves assemblies to be certain of this, especially as I expect this is something that also changes between versions of Ninject and may depend on how the library is being used.

The 'Copy referenced assemblies to workspace' setting has a serious impact on the performance of NCrunch. When this setting is enabled, NCrunch will execute build chains in a similar manner to Visual Studio, instead of trying to shortcut the build system by building projects independently. This greatly increases the amount of build effort required before tests can be run, thus slowing down the engine. The setting should be considered an option of last resort rather than a default mode of operation. NCrunch will enable it automatically for setups that are known to have no way around it (such as when MSTest private method accessors are being used), but this is usually reserved for build-time frameworks rather than run-time ones.

Hi Remco, Thanks for outlining your views.

I started writing a post explaining why I disagree, centred around an argument that the Conventions library is specifically about loosely matching Assemblies by examining the Assemblies it can see around it.
... Except half way through I realised that it wasn't the other code assemblies that it was not finding ... it's the Ninject dll that's not being found.

So the issue is presumably that the Conventions library is trying to dynamically load the Ninject Library at runtime!? Weird.

I may try to dig further into this, but for the moment I agree that, whilst the "Copy referenced assemblies to workspace" may be an easy quick fix, it's not necessarily a necessary or correct fix.

But for future developers suffering the problem. That setting does fix it :)
(@Remco, can you / do you want to edit the thread subject line to indicate that a fix was found, albeit a debatably imperfect one?)

Brondahl wrote:
But for future developers suffering the problem. That setting does fix it :)
(@Remco, can you / do you want to edit the thread subject line to indicate that a fix was found, albeit a debatably imperfect one?)

Unfortunately this forum doesn't seem to let me rename the topic, though I'm sure others can still see the posts behind it. Most people show up here via google search anyway :)