Orleans: System.MissingMethodException Microsoft.Extensions.DependencyInjection version="2.0.0"

[AwsomeCode]

I have upgraded DependencyInjection Verison to 2.0.0 and at the time of silo startup getting below error
After downgrading to 1.1.1 it is working fine.

Method not found: 'System.IServiceProvider Microsoft.Extensions.DependencyInjection.ServiceCollectionContainerBuilderExtensions.BuildServiceProvider(Microsoft.Extensions.DependencyInjection.IServiceCollection)'.
Exception = System.MissingMethodException: Method not found: 'System.IServiceProvider Microsoft.Extensions.DependencyInjection.ServiceCollectionContainerBuilderExtensions.BuildServiceProvider(Microsoft.Extensions.DependencyInjection.IServiceCollection)'.
at Orleans.Runtime.Startup.StartupBuilder.ConfigureStartup(String startupTypeName, IServiceCollection serviceCollection)
at Orleans.Runtime.Silo..ctor(SiloInitializationParameters initializationParams)
at Orleans.Runtime.Host.SiloHost.InitializeOrleansSilo()

[ReubenBond]

@AwsomeCode it's because they made a breaking change in 2.0 where they now return a concrete ServiceProvider instead of IServiceProvider for now I recommend not upgrading to 2.0 for that reason.

Question is, how should we handle this? We can either force an upgrade to 2.0 in a patch release or we can pin the version below it or we can do nothing. Unfortunately we can't support both.

[AwsomeCode]

I am ok with the current feature of DI 1.1.1
I have added Autofac and it was also working fine.

[ashtonkj]

@ReubenBond when working with ASP.NET Core 2, they expect DependencyInjection Version 2.0.0. This would mean that anyone that uses Aspnet Core 2 for an Orleans Silo client will break unless the Orleans package is upgraded to support this. Personally, given the options that you mentioned, I would like to see a forced upgrade in a patch release. But that is just my 2c as a consumer. If you want, I can open a PR to update these packages?

[sergeybykov]

Personally, given the options that you mentioned, I would like to see a forced upgrade in a patch release.

It looks like even though upgrading dependencies in a patch release is not a good thing, it's the least bad option here, as people are likely to ASP.NET Core 2 more and more.

[sergeybykov]

BTW, looks like this is a duplicate of #3325.

[jdom]

hmmm, kind of tough call, because the opposite is also true. If people are in ASP.NET Core 1.0 and want to stay with that, then they will not be able to update Orleans, since it will break for them.

Still, I imagine people using ASP.NET Core 1 are more likely to want to update to ASP.NET Core 2 now that it was released, especially if they also were upgrading the Orleans version. Granted, they might be OK upgrading the patch version of Orleans, but not necessarily a full upgrade of a major version of ASP.NET.

Nevertheless, if it was just for that, I would probably still recommend to upgrade to 2.0.0 for the DI package.

But there's another annoying thing with the upgrade: it means that a patch release of Orleans will now reference a .NET Standard 2.0 package, which requires end-users to be on the latest tooling (I think including installing the .NET Core 2.0 SDK) even if they are not touching any .NET Core code, and just sticking with the .NET Framework

[ashtonkj]

@jdom Agreed it is a tough call. Is there anyway that you can only use these packages in the 2.0 Preview releases (Without interfering with the >1.5 and < 2.0 releases)?

[jdom]

Absolutely, we are in the middle of a big restructuring of the code, and we can release a refresh of the 2.0 preview with this change soon

[ashtonkj]

@jdom thanks. Any idea when soon will be. I'd like to get in with testing it as soon as possible (I am loving Orleans so far, and think it is just getting better).

[jdom]

BTW, if there are no other incompatibilities when the different versions of the package, you can consider just creating a Startup type in your configuration, and call BuildServiceProvider() yourself, as you would be targeting the 2.0.0 version of DI explicitly, so no runtime binding redirect will occur that could lead to this exception.
Can someone try this instead of forking the repo? If this works, we can add the workaround in the releases section.

[jdom]

Hmm, never mind, as the issue is probably on the client library, which is where Asp.NET Core is probably hosted, and as far as I know there is no way to replace the call to BuildServiceProvider in the client, only in the Silo.

[ashtonkj]

@jdom sadly you are correct. The problem is on the client side.

[asterius1]

3356 fixes the issue for me when testing in ASP.NET Core 2.0 (netframework) and building orlens with .\build.cmd netfx

needed to change:
```c#
GrainClient.Initialize(config)

```c#
using Microsoft.Extensions.DependencyInjection;
...
client = new ClientBuilder().UseConfiguration(
    config
).UseServiceProviderFactory(services => services.BuildServiceProvider()).Build();
client.Connect().Wait();

and GrainClient usages change from
```c#
vat helloGrain = GrainClient.GrainFactory.GetGrain(0);

```c#
vat helloGrain = client.GetGrain<IHello>(0);

[jdom]

Thanks @asterius1 for confirming that it solves the issue.
With regards to the GrainClient static facade, that one is already obsolete and we expect users to switch to the non-static ClientBuilder and IClusterClient soon anyway, as we are probably going to remove it entirely in Orleans 2.0 (or right after that, still need to figure it out)

[ashtonkj]

As a consumer of the Orleans project, that kind of breaking change seems to fit perfectly with a major version number bump, so changing it for Orleans 2.0 makes the most sense from my side.

[ralexand56]

This is so freaking frustrating. All the time wasted on this. Why was this closed? I'm still getting the error and now even on the host. I deleted every bin and obj folder in my solution and still get this error.

[ralexand56]

Ok, anyone else having this problem you need to go to your nuget package manager and confirm that you're using Microsoft.Extensions.DependencyInjection version 1.1.1. You will likely need to downgrade.

[sergeybykov]

@ralexand56 Can you conform that after downgrading Microsoft.Extensions.DependencyInjection to 1.1.1, it is working for you?

Orleans 2.0 (Tech Preview at the moment, beta soon) already references Microsoft.Extensions.DependencyInjection 2.0.0 to resolve this.

[ralexand56]

Yes, everything seems to be working with that downgrade.

[dandago]

How do you go about doing this downgrade? NuGet won't let me:

```
Install-Package : Detected package downgrade: Microsoft.Extensions.DependencyInjection from 2.0.0 to 1.1.1. Reference the package directly from the project to select a different version.
[...] (>= 1.0.0) -> Microsoft.AspNetCore.Mvc (>= 2.0.0) -> Microsoft.Extensions.DependencyInjection (>= 2.0.0)
[...] (>= 1.0.0) -> Microsoft.Extensions.DependencyInjection (>= 1.1.1)
At line:1 char:1

• Install-Package Microsoft.Extensions.DependencyInjection -Version 1.1 ...
• ~~~~~~~~~~~~~~~~~
  
  
  
  • CategoryInfo : NotSpecified: (:) [Install-Package], Exception
  
  
  • FullyQualifiedErrorId : NuGetCmdletUnhandledException,NuGet.PackageManagement.PowerShellCmdlets.InstallPackageCommand
    
    ```
  
  

...and I can't reference it directly as suggested either.

I don't get how this can work though since it is a transitive dependency. I don't reference Microsoft.Extensions.DependencyInjection directly; it's a dependency of Microsoft.Orleans.Core (and, well, Microsoft.AspNetCore.Mvc).

[dandago]

I only managed to get this working by completely downgrading to ASP .NET Core 1.x.

I really think Orleans should decouple itself from such dependencies that force developers to target a particular framework.

[shlomiw]

Hi, I have this issue as well. I want to integrate Entity Framework Core 2.0 (requires .Net Core 2) with my silo and clients.
I'm still on Olreans 1.5 and if there's a workaround without upgrading to Orleans 2.0 (until the stable release) I prefer it.
@asterius1 suggested a workaround I would like to try but I need #3356 which isn't in the 1.5.2 branch (or is it targeted to the 2.0 branch?).

Any help here would be appreciated.
Thanks

[rsvaidya]

Hi,

We have this issue as well. Downgrading to 1.1.1 version of DependencyInjection is not an option for us, because we use this package is multiple libraries involving both .NET framework 4.7.1 and .NET Core 2.0, and our deployment is structured such that we can have only one version of a particular NuGet package for the entire product. Version 1.1.1 of DependencyInjection does not support .NET Core 2.0

Please consider reopening this issue.

Thanks.

[ReubenBond]

@rsvaidya are you able to use a custom build of Orleans to solve your issue until Orleans 2.0-final is released? Otherwise, are you able to use a beta version?

[adamrodger]

Is there any way that a 1.5.4 release could be made that includes the #3356 patch? That would be the best of both worlds - you can upgrade to 2.0 if you want to, or if you're unable to do that right now then you can install 1.5.4 and use the workaround until you can upgrade to 2.0.

At the moment we're stuck in a situation where we either have to stay on an old version of ASP.Net Core (and any other libraries that use Microsoft.Extensions.DependencyInjection 2.0) or upgrade our entire application to Orleans 2.0. Eventually we'll upgrade, but that's not a quick job on a large project so a release that makes the transition easier would be greatly appreciated.

[eckerdj7]

I'm having this issue, too. But when I downgrade I instead start getting a FileNotFoundException on System.Runtime...

[sergeybykov]

@eckerdj7 Can you open a separate issue with more details? I suspect your case might be different, as you are using 2.0, right?

[eckerdj7]

@sergeybykov No, this was using 1.5 also. This was just on a test project I setup trying to figure out my other issue I had, which you guys just helped me solve. But I was hoping to use that one for testing other things still. Should I still open a new issue for it?

[sergeybykov]

@eckerdj7 If that was with 1.5, then I don't see a point in opening another issue.