If an assembly that is to be modified by InjectModuleInitializer contains attributes with constructor parameters or properties of a type defined in a third-party library, Mono.Cecil will often fail to load that third-party assembly. This is the case because, by default, Mono.Cecil only searches for assembly files in "." and "bin", relative to Directory.GetCurrentDirectory() (see exhibit A and exhibit B). Unless the current directory is the same directory as the assembly to be modified (which is not the case in the InjectModuleInitializer nuget package), this causes a failure with a "Failed to resolve Assembly" message.

For example, if the to-be-modified assembly has a dependency on Newtonsoft.Json, and it has classes defined like the following, InjectModuleInitializer will fail:

// MemberSerialization.OptIn is defined in Newtonsoft.Json.dll and can't be located by
// Mono.Cecil. It isn't the JsonObject attribute, but rather its constructor parameter that
// is the problem. InjectModuleInitializer will fail if a class like this is defined.
[JsonObject(MemberSerialization.OptIn)]
public class Foo
{
}

// This class will cause InjectModuleInitializer to fail for the same reason.
[JsonObject(MemberSerialization = MemberSerialization.OptIn)]
public class Bar
{
}

This pull request adds the directory of the to-be-modified assembly to Mono.Cecil's search path so that the assembly where those attribute parameters exist can be successfully loaded.

Fixes #8. (I work at the same company as @killyosaur and obtained his code in order to figure out exactly what was happening. It turns out the problem had nothing to do with Visual Studio 2015.)