If a provider references a nestandard1.5 dll, it gets dependencies from System.Runtime.dll 4.1.0.0.
Anyway other project may reference System.Runtime.dll 4.3.0.0 nuget package and adjust the bindingRedirect directives in order to match the version.
The problem is that eventregister makes a strong check against the references loaded in the secondary AppDomain and does not accept 4.3.0.0 at all.
I understood the behavior by looking the eventregister.exe in ILSpy, when the references written in the rsp file get loaded:
// Returns a string containing the assembly display name after policy has been applied.
string text = AppDomain.CurrentDomain.ApplyPolicy(args.Name);
try
{
assembly = Assembly.ReflectionOnlyLoadFrom(assemblyFile);
}
catch { }
if (assembly != null && assembly.FullName == text)
{
return assembly;
}
By comparing with "==" assembly.FullName == text includes the version and makes the bind fail.
The problem gets worse when in the same solution there are other projects that do require System.Runtime version 4.3.0.0. In fact on the build machine, depending on the order, the build may result in a successful or a failure depending on the last overwritten version of the System.Runtime.dll.
I tried to overcome the problem by extracting the 4.1.0.0 version into a separate folder and referencing directly with "add-reference, browse" and this works in Visual Studio 2015, but not on the build machine.
If a provider references a nestandard1.5 dll, it gets dependencies from System.Runtime.dll 4.1.0.0.
Anyway other project may reference System.Runtime.dll 4.3.0.0 nuget package and adjust the bindingRedirect directives in order to match the version.
The problem is that eventregister makes a strong check against the references loaded in the secondary AppDomain and does not accept 4.3.0.0 at all.
I understood the behavior by looking the eventregister.exe in ILSpy, when the references written in the rsp file get loaded:
By comparing with "=="
assembly.FullName == textincludes the version and makes the bind fail.The problem gets worse when in the same solution there are other projects that do require System.Runtime version 4.3.0.0. In fact on the build machine, depending on the order, the build may result in a successful or a failure depending on the last overwritten version of the System.Runtime.dll.
I tried to overcome the problem by extracting the 4.1.0.0 version into a separate folder and referencing directly with "add-reference, browse" and this works in Visual Studio 2015, but not on the build machine.