Split Microsoft.Extensions.Configuration-dependent features into a separate NuGet

[queil]

Description

FsConfig depends on Microsoft.Extensions.Configuration but this dependency is only needed when using IConfigurationRoot. Wouldn't it make sense to split the package in two so the users not using Microsoft's extension do not need to needlessly deal with this dependency?

Repro steps

Add FsConfig package to a project and do dotnet restore.

Expected behavior

Can reference a "core" FsConfig without dependency on Microsoft.Extensions.Configuration and the NU1603 warning does not appear.

Actual behavior

Getting this warning:

warning NU1603: FsConfig 2.1.5 depends on Microsoft.Extensions.Configuration (>= 0.0.0) but Microsoft.Extensions.Configuration 0.0.0 was not found. An approximate best match of Microsoft.Extensions.Configuration 1.0.0 was resolved.

Context

• Os: Ubuntu 18.04
• .NET Core 3.1.101
• FsConfig 2.1.5

[demystifyfp]

Thanks, @queil for raising this issue and sorry for the delayed response.

I agree with you on the dependency, and I also felt the same when adding the support for IConfigurationRoot. Then I found that FsConfig is most likely going to be used in the ASP.NET Core applications (either Giraffe or Saturn) and hence I left it like that.

I am just curious to know the nature of the application in which you are using FsConfig and also why this extra dependency is a real concern?

[queil]

@demystifyfp I think your assumption is mostly correct in typical enterprise apps. However, I mostly use F# in Suave-based DevOps apps and only setting config via env. variables. The extra dependency is a concern mostly from the purity point of view.

[demystifyfp]

Thanks, @queil
It makes sense to have a NuGet package without the dependency.

Currently, I don't have the bandwidth to work on this. Feel free to fork this repo and publish a new NuGet Package.

As this library is narrow and stable, I don't foresee a challenge maintaining a separate fork.