Dependency on privately-signed assembly 'Microsoft.Framework.DependencyInjection'

[Allon-Guralnek]

Pull request #827 added to OrleansRuntime.dll the following two assembly references:

Microsoft.Framework.DependencyInjection Microsoft.Framework.DependencyInjection.Abstractions

These are required for staring a silo. If they can't be found, the following exception is thrown:

System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.Framework.DependencyInjection.Abstractions, Version=1.0.0.0, Culture=neutral, PublicKeyToken=96418ba87a82bc1c' or one of its dependencies. The system cannot find the file specified.
   at Orleans.Runtime.Startup.ConfigureStartupBuilder.ConfigureStartup(String startupTypeName)
   at Orleans.Runtime.Silo..ctor(String name, SiloType siloType, ClusterConfiguration config, ILocalDataStore keyStore)
   at Orleans.Runtime.Silo..ctor(String name, SiloType siloType, ClusterConfiguration config)
   at Orleans.Runtime.Host.SiloHost.InitializeOrleansSilo()

Unfortunately, these two dependencies haven't been added to the appropriate .nuspec file, so they aren't installed automatically. But the real issue is, installing those NuGet packages manually doesn't solve the problem. After they're installed, you get the following exception when starting a silo:

System.IO.FileLoadException: Could not load file or assembly 'Microsoft.Framework.DependencyInjection.Abstractions, Version=1.0.0.0, Culture=neutral, PublicKeyToken=96418ba87a82bc1c' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
   at Orleans.Runtime.Startup.ConfigureStartupBuilder.ConfigureStartup(String startupTypeName)
   at Orleans.Runtime.Silo..ctor(String name, SiloType siloType, ClusterConfiguration config, ILocalDataStore keyStore)
   at Orleans.Runtime.Silo..ctor(String name, SiloType siloType, ClusterConfiguration config)
   at Orleans.Runtime.Host.SiloHost.InitializeOrleansSilo()

This is caused by OrleanRuntime.dll referencing a private version of the Microsoft.Framework.DependencyInjection.Abstractions assembly that is signed during build (this is done using a pre-build event, at OrleanRuntime.csproj:238). This private version is not available outside the Orleans build process. Using the publicly available assembly that you get from installing the Microsoft.Framework.DependencyInjection NuGet package doesn't satisfy the assembly reference, since the public key token is different. Therefore, any silo that uses the OrleansRuntime NuGet package built from a version of Orleans after pull request #827 fails to start with the above exceptions.

[jthelin]

@Allon-Guralnek - Could you try too see if PR #911 helps address this problem?

Still would need to fix the Orleans.Runtime.nuspec file to capture the missing dependencies, but the above PR should help soften the assembly references to just use short assembly name for matching.

[Allon-Guralnek]

@jthelin - This would only affect the build process, not the runtime binding which fails. It would produce the exact same assembly and the same exceptions. The requirement in .NET is that signed assemblies only reference other signed assemblies. Since the OrleansRuntime assembly is signed, it's not possible to reference Microsoft.Framework.DependencyInjection, which is unsigned. So a signed version is created in the build process, before compilation, so you end up referencing aa signed version. There's nothing you can change in the project files to fix this. From what I understand, there are only three options:

1. Stop signing the Orleans assemblies, so they can have unsigned dependencies. This would allow using the official Microsoft.Framework.DependencyInjection NuGet package.
2. Include the signed DI assembly (the .dll file itself) with the OrleansRuntime NuGet package. This would fulfill the assembly reference requirement.
3. Use an already signed DI NuGet package. Either ask your friends at Microsoft that publish it to sign it, or publish your own Orleans flavor of that NuGet, signed by you.

[sergeybykov]

I think https://github.com/dotnet/orleans/pull/910 is the actual solution for this. Redistributing somebody else's binaries with altered identities seem like a very bad idea to me.

[amccool]

When is Microsoft.Framework.DependencyInjection.* due to move from beta to released? At that point it would be signed (I assume). Seems like all of this "goes away" by using a DI package that is signed? Is there a strict need to use Microsoft.Framework.DependencyInjection, especially being that its in pre-release?

[veikkoeeva]

@amccool Being one of the people in favor in the original DI discussion (I don't recall the discussion thread now, @attilah and others may correct me), the discussion was that should we roll our own to Orleans or take advantange of what coming to the .NET framework at large. The idea here is of "least friction", pit of success, familiarity, taking advantange of work elsewhere etc. between parts of .NET. It looks like happens so we are early with this on Orleans and this signing hassle was a bit unanticipated.

In general it looks signing is a hassle and there a recent change to CoreCLR too, more at https://github.com/aspnet/Announcements/issues/86 (https://github.com/aspnet/dnx/issues/2157 and some others too, I see).

[gabikliot]

Looks like this issue was solved by #910, right?

[Allon-Guralnek]

Yep, solved.