Runtime: System.Configuration Namespace in .Net Core

Created on 19 Mar 2017  路  35Comments  路  Source: dotnet/runtime

What is the suggested replacement for System.Configuration in .Net Core? I have an application which relies heavily on the custom configuration files. The system uses classes such as ConfigurationElement, IConfigurationElementCollectionElement .

ASP.NET Core project has a configuration system via Microsoft.Extensions.Configuration, but that is not in place replacement for old System.Configuration namespace. What is the long term approach for supporting configuration management in .Net platform?

area-System.Configuration question

Most helpful comment

ad System.Configuration.ConfigurationManager solved my issue.

All 35 comments

@mvadu are you willing to give it a try? You will need to run on 2.0. (https://github.com/dotnet/corefx/blob/master/Documentation/project-docs/dogfooding.md) The package you then need to reference is https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Configuration.ConfigurationManager
If you're on ASP.NET Core, you'd need dogfooding instructions specific to that.

@danmosemsft sure, I will try it this weekend. I am using the configuration system in a classic console app

I wanted to try this out using Dan's instructions however when I ran Install-Package I got the following error:

Install-Package : Package System.Configuration.ConfigurationManager 4.4.0-preview1-25131-05 is not compatible with netcoreapp2.0 (.NETCoreApp,Version=v2.0). Package
System.Configuration.ConfigurationManager 4.4.0-preview1-25131-05 supports:

  • net461 (.NETFramework,Version=v4.6.1)
  • netstandard2.0 (.NETStandard,Version=v2.0)
  • uap10.1 (UAP,Version=v10.1)

I then tried changing my csproj to target netstandard2.0 instead and got lots of these errors:

Severity Code Description Project File Line Suppression State
Error CS0012 The type 'Object' is defined in an assembly that is not referenced. You must add a reference to assembly 'mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'. Quantifi.Configuration(netstandard2.0) C:dev\Quantifi\projects\DotNetCore\core\Quantifi.Configuration\src\ObjectAppender.cs 19 Active

I was following the instructions on this page (Option 2: self-contained): https://github.com/dotnet/corefx/blob/master/Documentation/project-docs/dogfooding.md

On a related note, I would never have found this package on MyGet without specific instructions. I thought I should have been able to select a feed and then search based on a partial string (e.g. System.Configuration) and find any matching package ids but this did not work). Am I doing something wrong or is this just a "feature" of MyGet.

Finally, can you explain the version numbering scheme? I only found a "4.4.0-preview1" version of System.Configuration.ConfigurationManager. I was expecting a "2.0.0-preview1" package that matched the version of the CoreApp package.

Also, can you explain what this sentence means on the dogfooding page:

"However, there are times when you need to use a nightly build of Microsoft.NETCore.App which hasn't made its way into the SDK yet. To enable this, there are two options you can take."

I thought Microsoft.NETCore.App was the SDK.

The question about searching packages is less important. Although I cannot do so on MyGet the way that I expected I am able to do so from VS.

This is weird - @JeremyKuhne @weshaggard @ericstj can you please help?
I would expect that System.Configuration can be easily used by netcoreapp20 as it supports netstandard2.0. Maybe some bug or incomplete instructions?

@mtraudt What version of visual studio are you using?

@davidfowl
Microsoft Visual Studio Professional 2017
VisualStudio/15.0.0+26228.12

Sounds to me like you have an old NuGet since it's saying netstandard2.0 is not compatible with netcoreapp2.0. I don't see anywhere in those instructions info about updating VS / nuget vsix but that's what's required for this to work in VS.

Thanks. By old do you meant 3.5? That is what I have on the PC where I reported the problem. I will upgrade to 4.0 and try again later today.

You need a specific prerelease version of NuGet that has the compatibility mapping. That appears to be missing from https://github.com/dotnet/corefx/blob/master/Documentation/project-docs/dogfooding.md. @danmosemsft do you have steps for folks to use VS for this, or only commandline?

I have not created VS steps except for the note at the bottom of https://github.com/dotnet/corefx/blob/master/Documentation/project-docs/dogfooding.md. Could you help augment that then?

Okay thanks. After downloading NuGet 4.0 I was able to restore packages and build successfully if I manually added the package references to my csproj and used the CLI to build and run, but am still having problems if I try to install packages using VS. I will take a look at the updates to the dogfooding page when I have time and will help to augment if I can.

Probably unrelated, my test program references both System.Configuration.ConfigurationManager as well as log4net (2.0.8) and I am getting a lot of package downgrade warnings with this combination, eg:

C:dev\dotnet-dev-win-x64.latest\sdk\2.0.0-preview1-005685\NuGet.targets(97,5): warning : Detected package downgrade: System.Threading from 4.3.0 to 4.0.11 \r [C:dev\Quantifi\projects\DotNetCore\DotNetCore.sln]
C:dev\dotnet-dev-win-x64.latest\sdk\2.0.0-preview1-005685\NuGet.targets(97,5): warning : Quantifi.Configuration (>= 1.0.0) -> log4net (>= 2.0.8) -> System.Net.Requests (>= 4.0.11) -> System.Net.Primitives (>= 4.0.11) -> runtime.win.System.Net.Primitives (>= 4.3.0) -> System.Threading (>= 4.3.0) \r [C:dev\Quantifi\projects\DotNetCore\DotNetCore.sln]
C:dev\dotnet-dev-win-x64.latest\sdk\2.0.0-preview1-005685\NuGet.targets(97,5): warning : Quantifi.Configuration (>= 1.0.0) -> log4net (>= 2.0.8) -> System.Threading (>= 4.0.11) [C:dev\Quantifi\projects\DotNetCore\DotNetCore.sln]

I can investigate but if you have a quick answer as to the cause and what I should do (if anything) to resolve that would be appreciated. Log4net 2.0.8 targets netstandard1.3, by the way.

@AlexGhiondea can you take a look

@mtraudt what is that test program targeting? Can you share the project (and the assets file from the obj folder)?

I have attached my project (in zip file) and Nuget.config (renamed to Nuget.txt).

Other details:

1) Using 2.0.0-preview1-005724
2) Using CLI only (no Visual Studio)
3) Windows 10 Insider Preview 15063 (although having same problem with Anniversary update)

NuGet.txt

MyConsoleApp.zip

I did not include anything from the obj folder in the zip file. If you need that, let me know.

This is happening because log4net is using a mix of 1.0 and 1.1 packages. When restored for a specific runtime this brings in the implementation packages from 1.1 for all the packages (via the Microsoft.NETCore.Targets package and the runtime.json within it). These packages have all 1.1 versions in their closure and NuGet sees log4net's references as causing downgrades.

You can reproduce with netcoreapp1.0 self-contained app that references log4net using the RTM tooling. You don't end up seeing it on netcoreapp1.1 because MS.NETCore.App 1.1 will reference the 1.1 version of all of those packages.

We could fix this up in NETCoreApp 2.0 by including a new version of Microsoft.NETCore.Targets that had an empty runtime.json. This would upgrade the one referenced by the 1.1 packages and prevent any of the old runtime packages coming into the graph. I just deleted that package so we'd have to bring it back. @weshaggard what do you think?

@emgarten this is very similar to the problem we were looking at with UWP and Json.Net the other day.

I've opened a seperate issue to represent this downgrade warning: https://github.com/dotnet/corefx/issues/18088.

Let's keep this one on topic about consuming netcoreapp2.0 bits in VS. @danmosemsft what are the next steps on that?

Am I correct that we just need someone to write up those steps to patch VS with updated Nuget binary - there's no technical issue (save something related to this library)?

I believe so, but I haven't yet seen any steps shared in this thread or in the doc. @eerhardt do we have steps that folks need to follow to use the latest SDK to target .NETCoreApp 2.0 and .NETStandard 2.0 from VS 2017? I believe it involves installing a new VSIX and setting some property to change where the SDKs are loaded from.

As far as I know, it involves installing a NuGet VSIX that isn't available publicly. I have been able to do some VS work in the dotnet/cli repo, but we aren't using netstandard2.0, only netcoreapp2.0 referencing netstandard1.x libraries.

Also, I've been pretty successful using VS Code and the command line, if someone is looking to go that route.

To answer you specific question, I don't know of any documented steps to be able to target 2.0 from VS 2017 RTM. The current plan is you will need a VS update.

@livarcocc @nguerrera @dsplaisted

Speaking as CTO of a company that wants to migrate services to .NET Core but is waiting on 2.0, we can get by with CLI for now but VS support would obviously be an advantage. I believe MS has said Q2 for preview and Q3 for RTM. Since we are in Q2, are you able to narrow down those dates?

@Mtraudt that sounds right. @leecow have we more detail to share yet?

@mtraudt currently the only official date is in dotnet/corefx#17619 for zero-bug-bounce on May 10 for .NET Core 2.0. Hope it helps.

I am closing this and opening another for clarity.

Hi.

.NET Core was released. System.Configuration types should be in class library for .net core. But it's very hard to understand how to use them.

A project which uses types from System.Configuration namespace won't compile:

The type or namespace name 'ConfigurationSection' could not be found (are you missing a using directive or an assembly reference?)

VS (2017.3) doesn't suggest any fix for System.Configuration.ConfigurationSection type usage.

There's no a nuget package System.Configuration in nuget.org. But there's a package System.Configuration.ConfigurationManager.
Installing it helps compiling. But it looks strange for me. Why is it named System.Configuration.ConfigurationManager not System.Configuration? Is it actual package or something obsolete?

If we read the[doc Packages, Metapackages and Frameworks, it states that it's better to use metapackages. And there's a .NET Core metapackage - Microsoft.NETCore.App. It's installed in my project. And I can see it contains System.Configuration subnode. But the compiler can't see System.Configuration.ConfigurationSection. Why?

So, please, confirm or disprove that I'm correct about using System.Configuration.ConfigurationManager package for System.Configuration types (should be used or not).

P.S. Also in general it'd be nice to have some guidance how to find appropriate package for a class library type. I'd expect to find such info in reference doc, like https://docs.microsoft.com/ru-ru/dotnet/api/system.configuration.configurationsection?view=netcore-2.0
But it only has info on assemblies:

Assemblies:
    System.Configuration.dll, System.Configuration.ConfigurationManager.dll 

BTW, why are there two assemblies for system.configuration.configurationsection?

@JeremyKuhne should be able to answer and suggest documentation changes.
cc @mairaw as heads up for potential docs changes.

Why is it named System.Configuration.ConfigurationManager not System.Configuration?

We created a different assembly name for this as the types were spread across more than System.Configuration.dll in NetFX (desktop).

@weshaggard Can you clarify the expectations here for System.Configuration usage?

I can't reference System.Configuration.ConfigurationManager only System.Configuration.Assemblies any ideas on what I'm doing wrong?

@jonathanfishbein1 have you added a reference to the System.Configuration.ConfigurationManager package?

ad System.Configuration.ConfigurationManager solved my issue.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

noahfalk picture noahfalk  路  3Comments

iCodeWebApps picture iCodeWebApps  路  3Comments

omajid picture omajid  路  3Comments

matty-hall picture matty-hall  路  3Comments

bencz picture bencz  路  3Comments