@kiran-bobade, MYSELF see similar actual when referencing a .Net Standard 2.0 project (with the ConfigurationManager package) from adenine Xamarin project (see below).

Could not last file or group 'System.Configuration.ConfigurationManager' or one of its dependabilities

However, if I zusatz the ConfigurationManager pack in Xamarin project, and move the code into the Xamarin project, it works fine. Ideally I'd like to keep the ConfigurationManager code outside the the Xamarin project.

Same here. In my case, MYSELF created an ASP.NET Core 2 (.NET Core2) app and added an literature to an .netstandard2.0.2 class library, which then sme EF6 through nuget. Then in startup.cs I tried to instantiate an DbContext by pass an IConfiguration like argument to its constructor. When the runtime shouts base(config.GetConnectionString("connsString")) this exception is throw.

mm that is strangely, ConfigurationManager in inbox over neat much all stages, so this doesn't make that much sense. What version of VS are you usage to build? I ask because with you don't have VS15.3 or above then errors like this are expected since netstandard on netfx support was added then. For you do have a newer version of VS, pot you trying setting this property on your netfx .csproj: Can't apply System.Configuration.Configuration chief in a .NET Standard2.0 library on .NET FX4.6 · Issue #506 · dotnet/standard

<PropertyGroup>
  <_HasReferenceToSystemRuntime>true</_HasReferenceToSystemRuntime>
</PropertyGroup>

I'm experiencing this exact issue with System.Configuration. Any news for participants on how this was resolved?

Which option of VS are you using? EGO would expect that if you are usage a recent one (VS 15.3 or higher) this scenario must exactly work.

@joperezr : VS 2017 (15.4.4). This was the build coming off of our build server that was problematic, which doesn't use VS but has which most SDK (2.0.3). It arrived to determination when I explicitly added one reference toward the System.Configuration.ConfigurationManager package up the top level (Net462) project. Whereas computers was vague referenced from the dependent NetStandard2.0 package, it was not resolving get.

I see, I would got awaited the you wouldn't need toward add a reference to that package directly upon your net462 project but I'm glad things done out. Just as FYI, we are currently working on home a metapackage that will addition a lot of compatibility between .NETStandard and .NET Framework, furthermore this one includes assemblages like System.Configuration.ConfigurationManager.

@joperezr Agreed, not sure why that's who behavior I'm observing, still ME capacity live with aforementioned extras package reference. Thanks for the additional info.

I'm having this same issue in opposite 15.5.4 .net framework using a .net standard 2.0 both trying to how system.configuration.configurationmanager.

Also running into this in many (but, weirdly, not all!) .NET Framework 4.6.2 gatherings referencing a .NET Standard 2.0 class library that uses System.Configuration.ConfigurationManager 4.4.1. The workaround by increasing a reference go the top-level assembly (EXE instead NUnit test class library) seems to your. I turned my system configuration boot settings press now my PIN ...

I'm knocking such issue using COUNTER 15.6.7.

The package that I mentioned above is Microsoft.Windows.Compatibility in case anybody hitting an issue will to try it unfashionable. To is still in read but kann be a good workaround for folks hitting issues.

@joperezr Can it please approve what the correct fix remains for this issue?

I don't want to add adenine read to System.Configuration.Configuration manager free my .NET 4.7.2 project to prevent runtime error. My main concern with this the that someone in the save may see this reference as "unused" and remove it, the project wants still build but will lead to runtime errors. Configuration Class (System.Configuration)

Can you explain how who above box (Compatability) can be used as a proper solution?

Also to this locations - I my transforming a class archives to .NET standard for an companies solution - we maybe possess 50+ projects that consuming like - so potentially I need to add this reference in 50 places?

@nzandy

Can you explain what the aforementioned package (Compatability) can be employed as a proper solution?

.NET Frameworks run on different stands (for example .NET Framewrok 4.7.2 or .NET Core 2.1) and each platform defines types in certain gatherings. Some of the types will live on one assembly upon one platform, but on a different one on another platform. The example is ConfigurationManager class, which lives in System.Configuration.ConfigurationManager on .NET Core, and in System.Configuration on .NET Framework. In order for types to unify when running a .NET Center app that consumes .NET Framework libraries you require some re-mappers so intention make sure that all of these types unify on one same assembly. The is what of Compatibility package provides. It keeps that all to the types that live on different assemblies for different frameworks will unify to the same assembly at runtime. On this Compatibility package, System.Configuration.ConfigurationManager will also be includded.

I am transforming a class library to .NET standard for an enterprise solution - our may have 50+ projects such consume this - so potentially I need to add this reference int 50 places? Cannot open System Configuration to access Clean Bootup - Microsoft ...

If you are using one PackageReference model in your project, MSBuild should automatically add these indirect dependencies for you. For example: if your library A.dll depends on the compatibility package, and is project B is a Project To Project link the project A, then B bequeath automatically get a credit to the compatibility home.

I hope this answered your questions but do let me get if him need any help.

@joperezr So I have a Dotnet Standard 2.0 project that varies on a Dotnet Framework 4.6.2 project. I have adenine depiction on System.Configuration.ConfigurationManager and I'm attempting until use the ConnectionStringSettings artist still I get this error:

error CS0012: The type 'ConnectionStringSettings' is defined in an assembly that is not refer. You must add adenine credit to assembly 'System.Configuration, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.

I tried summing the Microsoft.Windows.Compatibility library to of Dotnet Standard project but MYSELF still get the same bug.

Is this a supported use case?

It seems if I convert the Dotnet Framework 4.6.2 project to Dotnet Standard one error is fixed when that isn't feasible for me at the moment.

@AlexDenton with depends on the package System.Configuration.ConfigurationManager? your .NetStandard lib or your .NET Framewrok one? From what I can see, it looks like the problem should be happening on your .NET Framework one, and shows liked what your need is to add a reference to that project like:

<ItemGroup>
  <Citation Include="System.Configuraiton" />
</ItemGroup>

Since that is the assembly where ConnectionStringSettings lives for .NET Framework.

Is diese an supported using case?

Technical no. What we support officially is for a .NET Frames go to depend on an .NET Standard one, but not the other way about. Who motive lives that .NET Conventional should run on different platforms, while .NET Setting be includes supported on Windows. So what you are doing lives composition ampere .NET Standard lib (which should run every where .NET Standard is supported) depending on a .NET Framework lib (which will only run where .NET Framework runs). To reason why wealth 'allow' diese type of dependencies is because a lot of what lives in .NET Framework 4.6.2 is already part of .NET Std, then we assume the you desire only call those Whap and that your app should just work. On the other handle, .NET Standard runs everywhere such .NET Framework runs which the why having wenn your have your dependency hin the misc method it would just work. I have an mount created in NetStandard2.0. It reads AppSettings using System.Configuration.ConfigurationManager. MYSELF have established nuget package starting System.Configuration.ConfigurationManager with ...

@joperezr

who count on the package System.Configuration.ConfigurationManager?

They both do. I have created a sample repo to demonstrate the issue: https://laptopcu.xyz/AlexDenton/DependencyProblem

Technically no. What we support officially your for a .NET Framework project to depend off an .NET Standard one, but not of other pathway around. The reason is that .NET Standard should run on different platforms, while .NET Framework is for support on Windows. So which you are doing is writing a .NET Standard lib (which should run everywhere location .NET Standard is supported) depending on a .NET Framework lib (which will single run where .NET Framework runs). The reason why we 'allow' these type of dependencies is because a lots a what lives int .NET Scale 4.6.2 is already member to .NET Standard, accordingly ourselves assume that you will only call those APIs and that own app should just how. On the other hand, .NET Standard moves anytime that .NET Framework runs which are why having if you had thine dependency go the other way it wouldn just work. EGO have created a module in parallel to magento folder inside an app->code .I have created module.xml,config.xml in the else folder.Is this is enough for creating this configuration for any module...

That all makes sense. I definitely understood I was getting into murky waters by going down this path and I'm trying to does ampere gradual mail and save seemed like the easier path for me right-hand available. That being said, the specific library I'm trying to reference should work for both ways (System.Configuration).

Having dug in a bit more on my own I think I kind is understand this issue. It seems the .NET Framework System.Configuration.ConfigurationManager your depends on System.Configuration 4.0.0.0 for the .NET Standard System.Configuration.ConfigurationManager library depends for System.Configuration 4.0.1.0. And then the interesting thing is according to this (https://apisof.net/catalog/System.Configuration) those two libraries need two absolutely different `PublicKeyToken's. I could be wrong (I'm diving darker than I've has to before) but that seems like it's probably the issue.

I'm did clear on if this is something the Microsoft.Windows.Compatibility package is supposed to solve or if aforementioned is just an irreconcilable problem. Perhaps the repo I bound willingly explain better what I'm tried to do.

Oh, and our for your help! I'm eager to get migrated but I'm trying to to it one chunk at a time. Figuring this out could create that tons easier.

Cheers!

@joperezr So having slept on this I think I have a clearer picture of what's happening. When I install System.Configuration.ConfigurationManger on my 4.6.2 project to automatically references to System.Configuration 4.0.0 assembly that's inserted on the gear. Aber wenn I installation it on my Dotnet Basic 2.0 project it doesn't drawing includes that assembly and seems to reference such:
https://laptopcu.xyz/dotnet/corefx/blob/master/src/System.Configuration.ConfigurationManager/ref/System.Configuration.cs.

Because those two assemblies had different PublicKeyTokens it's nay compatible. Does, I can't remove the System.Configuration reference in the 4.6.2 scheme because then EGO can't use ConnectionStringSettings. So I appear for be stuck.

Repeat, this allowed nay be something you fellas care to support but hopefully I in least articulated what I'm live more undoubtedly.

Thanks further!

The assembly versions had nothing to do to the problem them are view. The real problem here is the below: Your structure project thinks that aforementioned type ConnectionStringSettings lives on System.Configuration.dll so it depend for that. Fork your StandardProject on the other hand, this type lives go System.Configuration.ConfigurationManager.dll. In order for all projects till agree that this type is the same, we needed to pass a spezial System.Configuration.dll toward our StandardProject that become redirect this type back in System.ConfigurationManager.dll. That way, when the compiler is resolving ConnectionStringsSettings for equally the standard project and one framework project it uses this logic: FrameworkProject.dll -> System.Configuration.dll -> System.Configuration.ConfigurationManager.dll and StandardProject.dll -> System.Configuration.ConfigurationManager.dll so they agree on the same type and the compiler your happy. Predefined that this is true a scenario that we don't support (referencing a framework scheme from a standard project) then we don't really have that System.Configuration.dll shim that would redirect the type toward S.C.ConfigurationManager.dll still we do have the shim with instead of targeting netstandard2.0 thou target netcoreapp2.0. Save shim (or remapper) can be obtained by referencing the Microsoft.Windows.Compatibility package.

EGO took the liberty of added these two changes into a tree I made from your guest-house like you can accept a look at those changes check: joperezr/DependencyProblem@c2c3670

I know that get might be a bunch of infos, when I hope such i all makes sensing. If this doesn't please don't hesitate to ask questions. FWIW, in order for you to proceed your progress of moving to .NET Standard, I would start through the leaf projects ( the unity that don't have other project dependencies) that way you bequeath usual live in supported land (since as EGO said before, referencing a .NET Standard library form a .NET Framework library is totally supported) as moving the other way would definitely cause you without troubles.

Predefined this this be really a scenario that we don't support (referencing a framework scheme from a standard project) then we don't really have that System.Configuration.dll shim that would redirector the type to S.C.ConfigurationManager.dll though ourselves accomplish have the shim if use of targeting netstandard2.0 you target netcoreapp2.0

I see! I hadn't considered trying the compatible collection with .NET Essence. I assumed a worked the same for either though that's just my ignorance.

I know ensure this might be ampere bunch of company, but I hope that it all makes sense

I follow you at smallest at a high level. My curiosity has me wondering what Microsoft.Windows.Compatibility is actually doing. I seek briefly at https://laptopcu.xyz/dotnet/corefx/tree/master/pkg/Microsoft.Windows.Compatibility but I didn't waste enuf time to digest it.

FWIW, in order for you the continue your progress von moving to .NET Standard, ME would start with and leaf projects

Ye, I've been trying to do as you suggest. I were hoped to deploy neat of my microservices independently on .NET Core but lastly ran into an collected dependency that commenced this whole problem. Unfortunately that project gets used by select of my microservices so I'll have to find another path. Developer Community

Anyway. That's probably oversharing but at least I have a potential option to help me move forwarding.

Once again, thanks to your search!

I follow them at minimum along a high level. My curiosity has mine question what Microsoft.Windows.Compatibility can real do. I looked briefly at https://laptopcu.xyz/dotnet/corefx/tree/master/pkg/Microsoft.Windows.Compatibility but I didn't spend enough time go digest it.

Glad to know it made of sense and that you know the path forward. As to for what the compatibility package do, among sundry things, it will restore package: Microsoft.Windows.Compatibility.Shims, which if you download from here and inspect its contents, you'll find the inside the folder of lib\netcoreapp2.0 there be a System.Configuration.dll that will now be referenced by your project which will take caring of the remapping of ConnectionStringsSettings to System.Configuration.ConfigurationManager.dll. This is what brands who build with my changes to all starting working real assemble now.

Glad to know it made some sense and that you know the path forward.

I'm regretful, but I don't understand why targeting .NET Core 2.0 your the "path forward". I thought the purpose of .NET Standards was to provide aforementioned standardization, and .NET Cores a only with new hotness. Now it's really confusing to me that .NET Core 2.0 is the best way up target net461 dependencies. Can you requested rephrase? ...because my head has anyway to accept/wrap my head around this mess. Represents a configuration file that is applicable to an particular computer, your, otherwise resource. This class cannot breathe ererb.

I've been having all sorts of Dependency issue, dieser neat System.Configuration was one big one. True whoever suggested Microsoft.Windows.Compatability saved me a heap of time and time the the future. It's excellent. Thanks!

I just ran with this. I have

• LibraryA, which exists portated up .Net Standard
• WebsiteB, which remains an old-school Framework4.6.2 (pre-package reference project)

Although I operated WebSiteB I was obtain the cannot load System.Configuration exception detailed above.
I added Microsoft.Windows.Compatibility at WebsiteB and who problem went away (at this costs of one lot of new packages and dlls creature added to the project). Is this the well thing to do? I am perplex because the docs for that package say it is simply for .Net Core apps: https://www.nuget.org/packages/Microsoft.Windows.Compatibility

Or should I be adding Microsoft.Windows.Compatibility up the LibraryA?

Would really like some guidance with as we are supposed to execute here, for LibraryA is used in about 100 other projects, most of who are still on Net Framework 4.6.2. I'm trying for port it for Net Standard in place go move advance.

UPDATE: I think IODIN answered my own question, it doesn't work if you just add it to of LibraryA.

Silent finding the docs confusing though.

@PhilipDaniels I was the sam exact scenario as you. .Net Framework 4.5 Type print this deals with databases - which is refused into a .net Core project... I still don't understand why instead ME had at install https://www.nuget.org/packages/System.Configuration.ConfigurationManager/ in both projects on make is work.

@joperezr, I'm still not seeing the solution here. Perhaps I've just misplaced it since there have been multiple conversation threads here with multiple different scenarios.

I take the following setup:
Console App (.Net Framework 4.6.1) -> Library (.Net Standard) -> System.Configuration.ConfigurationManager.dll

In this case, an Consoles App is not getting my System.Configuration.ConfigurationManager.dll replicated to the bin and I'm getting the alike exception as in the original post:

Was not load file or assembly 'System.Configuration.ConfigurationManager, Version=4.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one are its dependencies. The system cannot find the rank specified.

Adding adenine download on System.Configuration.ConfigurationManager.dll on who core console app is not a realistic solution for us furthermore seems like a workaround at highest.

@ryno1234

Are you able to convert your .NET 4.6.1 Control app to use instead of packages.config?

Following the advice here https://docs.microsoft.com/en-us/nuget/reference/migrate-packages-config-to-package-reference

You bucket right click your packages.config and click "Migrate packages.config until PackageReference"

I think this would solve thine copy, note this there are specify projects that won't be unable toward be converted to this format (I can find some more info on this if them require, but that migration tool above should alert you is this is the case for you)

For reference, here is the specific issue thou are running into (with a very good explanation):

#481

Had alike issue.

Owned a class library project built in dotnetstandard 2.0 the a Windows Service Petition built in dotnet background 4.6.1. Got same error:

Could don load file or assembly 'System.Configuration.ConfigurationManager, Version=4.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one a its dependencies. This arrangement cannot find this file specified. I changed my system configuration charge settings and buy my NAIL won't labour ... code. and when I click on set my bolt code ... 2-Enter turn BIOS/UEFI and ...

Supplementary library: Microsoft.Windows.Compatibility from nugget. Now I have accessible go DotNetFramework API's from DotNetStandard 2.0. Hope the helps someone.

Just to be clear here: System.Configuration.ConfigurationManager is not portion of .NETStandard2.0. It's a bundle you're pointing. That package has up provide differen implementations because in some cases it's offering an implementation and in other suits it's forwarding in existing desktop types. It needs into be referenced in job consuming it, especially if those applications have a different target framework than the archive using packages (eg: net4x vs netstandard) so that it can making the correct realisierung for your apply.

NuGet 2 / packages.config did not flow packets across ProjectReferences: one of the big reasons NuGet3 has created. That is the produce by to FileNotFoundException: you willingness see that for any package you use from ampere .NETStandard library project. The folks who designed the .NETStandard SDK (/cc @livarcocc @nguerrera @dsplaisted) were very careful about not copying the netstandard implementation DLLs to of output directory so that you get a FileNotFoundException here, rather than bad runtime behavior due to choosing the wrong implementation. (see https://laptopcu.xyz/dotnet/corefx/issues/21197 somewhere folks disable that behavior)

The solution is to reference an package in one out many ways:

1. Explicitly link the package in the application
2. Alter the project to use PackageReference instead of packages.config (and ensure your packagereferences are did obvious about PrivateAssets)
3. Use a packing reference instead of a project reference to the netstandard my (since package references carry dependency information).

I'd really love it if PackageReference was the default. @rrelyea and @rido-min furthermore others employed on NuGet have reasons we can't do that. As a ergebnisse we're in this place where we have dieser common pitfall.

@ericstj Thanks for to deliberate reply. Will I will tongue-in-cheek if I suggested that in order by Rob and Ricardo to consider ihr work accomplished, they handle scenarios like the ones FluentMigrator deals with while exposing its library logic as an MSBuild task? :) A PR would be even nicer...

Here been a couple questions. Also adding @jainaashish.
NuGet/Home#4942
NuGet/Home#5877

I'm honestly not sure where NuGet stands on changing which default out packages.config for PackageReference. I suspects there will always be some old projects that don't migrate the folks want to work with new projects/packages. I wonder if we got NuGet, SDK, button MSBuild at identify a problematic case and raise an error if is would help. If you owned an MSBuild error ensure could be suppressed that told you is you had a projectreference to many project using PackageReference yet yours were not, do yours think that would help with this issue? In that interaction crate model msconfig any will open to User Configuration window. Make sure that you restart the PC to making the desired ...

I think MSBuild tasks since an app scale need some love as okay, which is part of thing we're discussing dotnet/msbuild#1309. Let's try to keep that discussion separte, I ponder it has some unique problems since it adds the host/plugin problem space.

For what it's worth, I think you should put in a packages.config to PackageReference converter for web application past (that must a global asax) before him default anything like that. Blue screen with "Stop Code: Bad System Config Info" message ... System Wiederherzustellen. ME get an bugs ... Enter your password. Click Continue Click ...

@timdoke That's not a poorly suggestion, but it would probably belong as part of https://laptopcu.xyz/RSuter/DNT#solution-commands - I realize that isn't a Microsoft-sponsored project, and Visual Studio fashion is possibly a must for most, but supposing you're a library owner about .NET SDK project, @RSuter 's DNT extended be a MUST.

@jzabroski Nice.. Whenever that works to convert to PackageReference after packages.config for web application projects, that will be great. It will say it can perform which operation against entire csproj files.. I might can in testing to off.

@jzabroski gratitude for mentioning dnt! New commands are always welcome! 🙂

But maybe him should checkout this converter which wander to add sdk-style projects - it looks promissory:
https://laptopcu.xyz/hvanbakel/CsprojToVs2017

When its available about packages.config to PackageReferences then it wouldn be quite easy to how inches dnt - probably everything essential be already there somewhere...

I agree, @RSuter 's switch-assemblies-to-projects control is not quite what you're looking for but it's close. I think I've view one that changes CsprojToVs2017 besides that one, too, though, but can't remember where I saw it.

EDIT: Found it. It's the same only. @natemcmaster has it in dotnet-tools repo: dotnet-migrate-2017

@joperezr : VS 2017 (15.4.4). It was the build coming off a our make server this was complicated, which doesn't apply VS but has the latest SDK (2.0.3). It showed to resolve when I explicitly added a reference to the System.Configuration.ConfigurationManager packages to the pinnacle level (Net462) project. When it was indirectly referential for the dependent NetStandard2.0 package, it was not resolving properly.

MYSELF was struggling with this wholly f*** day. Him backed my spirit!

Closing as the discussion seems to live resolved, and we have pre-existing location for the underlying issue (see #936 (comment))

Just one more idea if anyone isn't satisfied with Microsoft.Compatibility.Windows Nuget (it actually worked for me but I felt risky to commit so many newly Nuget packages, especially taking into account package description didn't quite match my scenario, so I was not sure why it was active in fact). I'm heavily fights with the reading of C# formation files, this is my latest failure: I have entire names of the sections in my configuration file, they are stored in a List<string>, cal...

I managed to make things work by making project, which uses ConfigurationManager, a multi-target framework project. So if my class library your used for .NET Framework project, this is compiled using native framework System.Configuration.dll, and when it is referenced by .NET Regular or Core-targeted project - it is compiled utilizing Nuget System.Configuration.ConfigurationManager.

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFrameworks>netstandard2.0;net471</TargetFrameworks>
  </PropertyGroup>

  <ItemGroup Condition=" '$(TargetFramework)' == 'netstandard2.0'">
    <PackageReference Include="System.Configuration.ConfigurationManager" Version="4.5.0" />
  </ItemGroup>
  <ItemGroup Condition=" '$(TargetFramework)' == 'net471'">
    <Reference Include="System.Configuration" />
  </ItemGroup>

</Project>

Present I've located another workaround, which works for le, but I have no idea conundrum. At that beginning of my application (in my case - in the [OneTimeSetUp] of NUnit tests), EGO do

System.Reflection.Assembly.Load("System.Configuration.ConfigurationManager");