Breakup dependencies, e.g. with Configuration

[divega]

Currently Options depends on Configuration because of the serviceCollection.Configure(configuration) overload.

This means that any package that indirectly depend on Options also depend on Configuration, e.g. Entity Framework 7 depends on Caching which depends on Options which depends on Configuration, therefore even if we made the explicit decision not to couple Entity Framework with Configuration, the dependency exists and is carried even to places where it isn't commonly used, e.g. desktop .NET or Windows UAP applications.

The dependency could be broken by splitting the parts of options that depend from configuration (e.g. serviceCollection.Configure(configuration) and its implementation classConfigureFromConfigurationOptions`) into their own package.

Optionally, moving that package in its own repo would help breakup the chain of build dependencies for our CI.

[HaoK]

Moving Config + Options into Options.ConfigurationExtensions

[divega]

Should we put that in a new repo to break the build dependency? cc @Eilon

[Eilon]

Can we put all of these in one repo instead?

[divega]

Possibly, if we can bring enough of the graph of dependencies together to avoid cycles. We should try.

[HaoK]

Options depends on DI and Config basically. Config doesn't depend on DI.

[HaoK]

Options should build pretty low in the stack, is there a ci build issue?

[divega]

The issue is that CI is slower than we want it to be, and one way we can improve that is to break dependency chains among repos, e.g. so that any time something changes on any given repo that doesn't trigger as many builds of other things.

[HaoK]

So we want to move the Configuration dependency outside of the Options repo? The problem is that Options depends on DI too, so we can't put it into Configuration.

[divega]

That is why I suggested a new repo. There is a obviously a balance between the overhead of maintaining yet another repo vs. the potential benefit breaking this particular chain. Others may have more context to evaluate that.

[HaoK]

ec13249 Options.ConfigurationExtensions

[kimballjohnson]

I am using the DotNetCore.1.0.0-VS2015Tools.Preview2.exe with Visual Studio Update 3. I am unable to migrate code to read settings in the appsettings.json file from an MVC6 app. It uses the @Inject Microsoft.Extensions.OptionsModel.IOptions Settings syntax in a razor file to read the configuration.
The only version of Microsoft.Extensions.OptionsModel.IOptions available is rc1, whereas the Microsoft.Extensions.Options.ConfigurationExtensions version is rc2.
Therefore I am getting the 'ambiguous call' error referred to in a related .net github issue:
Error CS0121 The call is ambiguous between the following methods or properties:
Microsoft.Extensions.DependencyInjection.OptionsServiceCollectionExtensions.Configure and Microsoft.Extensions.DependencyInjection.OptionsConfigurationServiceCollectionExtensions.Configure

Of course, all of this is part of the worst release mess I've ever seen in msland. But is there any solution for this particular bit of madness?

Thanks,
Kimball Johnson

[kimballjohnson]

leaving out the Microsoft.Extensions.OptionsModel.Options part I get this further error:
Could not load type 'Microsoft.Extensions.DependencyInjection.ServiceCollectionExtensions' from assembly 'Microsoft.Extensions.DependencyInjection.Abstractions, Version=1.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'.

[davidfowl]

Whenever you get errors like this you should do a dependency scan to make sure you're not mixing versions of things. If you upgraded your project from an rc1, make a new project and copy the assets over. RC2 -> RTM is more straight forward and there's a guide.