aspnet / DependencyInjection

[Archived] Contains common DI abstractions that ASP.NET Core and Entity Framework Core use. Project moved to https://github.com/aspnet/Extensions

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Breaking changes between 1.1.0 and 2.0.0-preview-2

alexvaluyskiy opened this issue · comments

There is a method in Microsoft.Extensions.DependencyInjection v1.1.1

public static IServiceProvider BuildServiceProvider(this IServiceCollection services)
{
	return BuildServiceProvider(services, validateScopes: false);
}

And a lot of projects are using this method, for example Orleans and OData.WebApi
https://github.com/dotnet/orleans/blob/master/src/OrleansRuntime/Startup/StartupBuilder.cs#L40
https://github.com/dotnet/orleans/blob/master/src/Orleans/Core/ClientBuilder.cs#L42
https://github.com/OData/WebApi/blob/maintenance-aspnetcore/vNext/src/Microsoft.AspNetCore.OData/Extensions/DefaultContainerBuilder.cs#L88

The problem is that in 2.0 this method changed the return type from IServiceProvider to ServiceProvider. When I'm trying to use ASP.Net Core 2.0 with Orleans I'm getting an exception MethodNotFoundException

Yes, this is one of the breaking changes that was made as part of 2.0. See #338. Those libraries will need to be recompiled against the newer DI to be compatible.

Fyi - this also breaks the xamarin linker. If you update your xamarin android application to use Microsoft.Extensions.DependencyInjection version 2.0.0 but you have a dependency compiled against v1.0.0 or v1.1.0 there is a linker problem. The update v2.0.0 in my case was because I wanted to use EF Core 2.0.0 in my application, which requires it. EF Core 2.0.0 appears to call BuildServiceProvider(). My dependency (which is compiled against v1.0.0) allows passing in a delegate which calls BuildServiceProvider() instead - which allows it to work with v1.0.0, v1.1.0 and v.2.0.0 which I thought was a good solution in this instance to still support applications using older versions of DI. The Linker however can't cope with this it seems and bombs out. Yet the application runs fine without the linker. Therefore this causes an issue for the xamarin tooling with seemingly no workaround except to recompile dependencies.