I have an assembly created in *NetStandard2.0*. It reads AppSettings using **System.Configuration.ConfigurationManager**. I have installed nuget package of **System.Configuration.ConfigurationManager** with version 4.4.X which is suitable for *NetStandard2.0*.

When I refer this assembly in console app (.Net Core) it is reading AppSettings properly, but when I refer this assembly in old .NetFramework(4.6.X) console app it is not working and throwing an exception.

Please see the code below.

**Assembly 1: NetStandard 2.0**

**Nuget: System.Configuration.ConfigurationManager 4.4.0**

    using System.Configuration;

    namespace Bootstrapper.Lib
    {
       public class Bootstrapper
       {
         public Bootstrapper()
         {
         
         }
       
         public void LoadAppSettings()
         {
             string serachPattern= 
             ConfigurationManager.AppSettings[&quot;AssemblySearchPattern&quot;];
         }
      }

    }

**Console App: NetFx 4.6.X**

    using System;
    using Bootstrapper.Lib;
    namespace Bootstrapper.Console
    {
      class Program
      {
        static void Main(string[] args)
        {
            new Bootstrapper().LoadAppSettings();
        }
      }
    }

**Exception After Run:**

    &#39;Could not load file or assembly &#39;System.Configuration.ConfigurationManager, 
     Version=4.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51&#39; or one 
     of its dependencies. The system cannot find the file specified.&#39;

It will work with Console App developed using .NetCore.

Please help!!!


Can&#39;t use System.Configuration.Configuration manager in a .NET Standard2.0 library on .NET FX4.6

I&#39;ve been mucking about with [a .NET Standard project][1] and NuGet. I&#39;ve got a working project and have [uploaded it to NuGet.org][2]. My project targets .NET Standard 1.3, which [should support][3] .NET Framework 4.6 and .NET Core 1.0.

But when I tried to add my project (via NuGet) to a fresh .NET Framework 4.6 project, the dependencies resolved to **47** packages! They&#39;re all system libraries and appear to be dependencies of either Microsoft.NETCore.Platforms or NETStandard.Library 1.6.1. ([Gist of full PM output.][4])

My project only imports (`using`) a handful of libraries, none of which I added manually; i.e. they&#39;re all libraries that &quot;came with&quot; .NET Standard. These libraries are:

 1. System
 2. System.Text
 3. System.Reflection
 4. System.Linq
 5. System.Collections.Generic;

The thing is, I decided to make my project target .NET Standard because I wanted it to work seamlessly across .NET Framework and .NET Core applications. I thought the whole point of Standard was to set a minimum level of compatibility. By extension, I suppose I had assumed (perhaps erroneously) that libraries like System.Console would be automatically available in either Core or Framework.

I didn&#39;t notice anything like this when I tested my Standard project as a dependency in a Framework and Core project within the same solution, so I&#39;m suspicious that this might be a NuGet thing.

What&#39;s really going on here? And how can I make my .NET Standard library available on NuGet without a huge list of dependencies?

Is it a problem with the way I&#39;ve specified my NuGet package? Or have I fundamentally misunderstood something?


  [1]: https://github.com/tdwright/contabs
  [2]: https://www.nuget.org/packages/ConTabs.tdwright/0.1.0
  [3]: https://docs.microsoft.com/en-us/dotnet/standard/net-standard
  [4]: https://gist.github.com/tdwright/0b3568a9da2e318fe6e3c2efc40fcff4

Why does my .NET Standard NuGet package trigger so many dependencies?

I&#39;m writing a class library for a simple parser in C#. When I first created it, I used .NET standard 2.0, but now I need to migrate it to .NET 4.6 both to conform to the other projects in my solution and in order to use NUnit.

I tried to follow the instructions [in the Microsoft documentation](https://docs.microsoft.com/en-us/visualstudio/ide/how-to-target-a-version-of-the-dotnet-framework), but when I try to select another framework in the properties, I can only find other .NET standard versions.

How can I migrate it? Will I need to manually edit the `.csproj` file?

How can I change a .NET standard library to a .NET framework library?

I have read about the difference between .NET Standard and .NET Core, but I really don&#39;t know what the difference is, or when to choose a .NET Standard library project and when to choose a .NET Core library project.

I have read that .NET Standard is to ensure that a set of APIs are always available, no matter the platform used (as long as that platform is compatible with the .NET Standard version that I have chosen). If I&#39;m not mistaken, this means that I can create a class library of .NET Standard and then use it on any platform that is compatible with the .NET Standard version that I have chosen.

With .NET Core, I have read that it is intended for cross-platform use too, so if I choose a .NET Core library it seems that I can use it on many platforms too, just like .NET Standard.

So at the end, I don&#39;t see the difference. When should I use which? What is the difference between them?

.NET Standard vs .NET Core

In Visual Studio, there are at least three different types of class libraries you can create:

* Class Library (.NET Framework)
* Class Library (.NET Standard)
* Class Library (.NET Core)

While the first is what we&#39;ve been using for years, a major point of confusion I&#39;ve been having is when to use the .NET Standard and .NET Core class library types. I&#39;ve been bitten by this recently when attempting to [multi-target different framework versions][1], and [creating a unit test project][2].

So, what is the difference between *Class Library (.NET Standard)* and *Class Library (.NET Core)*, why do both exist, and when should we use one over the other?

  [1]: https://stackoverflow.com/a/42748869/983064
  [2]: https://stackoverflow.com/questions/42938879/cant-get-xunit-tests-to-run-with-net-core


What is the difference between .NET Core and .NET Standard Class Library project types?

In Visual Studio 2019 Advanced Build settings, C# 8 does not appear to be available for a .NET Framework project, only (as in the picture below) for a .NET Core 3.0 project:

[![enter image description here][1]][1]

Does C# 8 support the .NET Framework?

  [1]: https://i.stack.imgur.com/3P2rH.png

Does C# 8 support the .NET Framework?

I&#39;ve got a method that reads settings from my config file like this: 

    var value = ConfigurationManager.AppSettings[key];

It compiles fine when targeting .NET Standard 2.0 only. 

Now I need multiple targets, so I updated my project file with: 

    &lt;TargetFrameworks&gt;netcoreapp2.0;net461;netstandard2.0&lt;/TargetFrameworks&gt;

But now, the compilation fails for `netcoreapp2.0` with the following error message: 

&gt; Error	CS0103	The name &#39;ConfigurationManager&#39; does not exist in the current context	(netcoreapp2.0)

Separately, I created a new .NET Core 2.0 console application (only targeting .NET Core 2.0 this time), but likewise there seems to be no `ConfigurationManager` under the namespace `System.Configuration`. 

I&#39;m quite confused because it&#39;s available under .NET Standard 2.0, so I would expect it to be available in .NET Core 2.0, as .NET Core 2.0 is .NET Standard 2.0 compliant. 

What am I missing? 


Is ConfigurationManager.AppSettings available in .NET Core 2.0?

I have just converted my PCL library to a new .Net Standard library and I have some Yellow Warning triangles on my Dependencies shown below:

[![enter image description here][1]][1]

During the conversion it brought all nuget packages across including dependencies so it could be dulicates.

How do I find out what the Yellow warning triangles represent?

**EDIT**

Build Logs:

&gt; To prevent NuGet from restoring packages during build, open the Visual
&gt; Studio Options dialog, click on the Package Manager node and uncheck
&gt; &#39;Allow NuGet to download missing packages during build.&#39; NU1605:
&gt; Detected package downgrade: NUnit from 3.8.1 to 2.6.4. Reference the
&gt; package directly from the project to select a different version.  
&gt; MyProj.UI.Tests -&gt; MyProj.Core.Tests -&gt; NUnit (&gt;= 3.8.1)  
&gt; MyProj.UI.Tests -&gt; NUnit (&gt;= 2.6.4) NU1605: Detected package
&gt; downgrade: NUnit from 3.8.1 to 2.6.4. Reference the package directly
&gt; from the project to select a different version.   MyProj.UI.Tests.iOS
&gt; -&gt; MyProj.UI.Tests -&gt; MyProj.Core.Tests -&gt; NUnit (&gt;= 3.8.1)   MyProj.UI.Tests.iOS -&gt; NUnit (&gt;= 2.6.4) NU1605: Detected package
&gt; downgrade: NUnit from 3.8.1 to 2.6.4. Reference the package directly
&gt; from the project to select a different version.  
&gt; MyProj.UI.Tests.Android -&gt; MyProj.UI.Tests -&gt; MyProj.Core.Tests -&gt;
&gt; NUnit (&gt;= 3.8.1)   MyProj.UI.Tests.Android -&gt; NUnit (&gt;= 2.6.4)

  [1]: https://i.stack.imgur.com/NhEd0.png

What do Yellow Warning Triangles mean on Dependencies in Visual Studio 2017?

I am currently playing around with the latest Visual Studio 2017 Release Candidate by creating a .NET Standard 1.6 library. I am using xUnit to unit test my code and was wondering if you can still test internal methods in VS2017.

I remember that you could add a line in AssemblyInfo.cs class in VS2015 that would enable specified projects to see internal methods:

    [assembly:InternalsVisibleTo(&quot;MyTests&quot;)]

As there is no AssemblyInfo.cs class in VS2017 .NET Standard projects, I was wondering if you can still unit test internal methods?

Unit testing internal methods in VS2017 .NET Standard library

This may be somewhat related to [Pass ILogger or ILoggerFactory to constructors in AspNet Core?](https://stackoverflow.com/q/46013762/91), however this is specifically about **Library Design**, not about how the actual application that uses those libraries implement its logging.

I am writing a .net Standard 2.0 Library that will be installed via Nuget, and to allow people using that Library to get some debug info, I&#39;m depending on [Microsoft.Extensions.Logging.Abstractions](https://www.nuget.org/packages/Microsoft.Extensions.Logging.Abstractions/) to allow a standardized Logger to be injected.

However, I&#39;m seeing multiple interfaces, and sample code on the web sometimes uses `ILoggerFactory` and creates a logger in the ctor of the class. There&#39;s also `ILoggerProvider` which looks like a read-only version of the Factory, but implementations may or may not implement both interfaces, so I&#39;d have to pick. (Factory seems more common than Provider).

Some code I&#39;ve seen uses the non-generic `ILogger` interface and might even share one instance of the same logger, and some take an `ILogger&lt;T&gt;` in their ctor and expect the DI container to support open generic types or explicit registration of each and every `ILogger&lt;T&gt;` variation my library uses.

Right now, I do think that `ILogger&lt;T&gt;` is the right approach, and maybe a ctor that doesn&#39;t take that argument and just passes a Null Logger instead. That way, if no logging is needed, none is used. However, some DI containers pick the largest ctor and thus would fail anyway.

I&#39;m curious of what I&#39;m _supposed_ to be doing here to create the least amount of headache for users, while still allowing proper logging support if desired.

Should I take ILogger, ILogger&lt;T&gt;, ILoggerFactory or ILoggerProvider for a library?

I have spent the better part of a few hours trying to find a way to auto-increment versions in a .NETCoreApp 1.1 (Visual Studio 2017).

I know the the AssemblyInfo.cs is being created dynamically in the folder: ```obj/Debug/netcoreapp1.1/```

It does not accept the old method of: 
```[assembly: System.Reflection.AssemblyFileVersionAttribute(&quot;1.0.0.*&quot;)]```

If I set the project to package I can set versions there but this seems to be used to build the AssemblyInfo.cs file.

My question is, has anyone figured out how to control version in .NET Core (or .NETStandard for that matter) projects.

Auto Versioning in Visual Studio 2017 (.NET Core)

There is a framework-level navigation element at Microsoft Docs called [&quot;.NET Platform Extensions&quot;][1]. It contains docs on recently added APIs like `System.IO.Pipelines` and `System.Threading.Channels` for example, as well as a whole bunch of other APIs, including the not-so-recent ones.

Some APIs from this collection are available as nuget packages (for both .Net Core and .Net Framework), but others are not seemingly available. Also, as of now, there is no nuget package called &quot;.NET Platform Extensions&quot; or anything similar.

So, the question is what exactly does this collection of APIs represent? What is it&#39;s relationship to each of the following:

 - .Net Framework
 - .Net Core
 - .Net Standard

What about support in the .Net Framework / .Net Core?

Finally, some APIs seem to be already available as separate nuget packages, others are yet to be made available, so what is the story in that regard?

  [1]: https://docs.microsoft.com/en-us/dotnet/api/index?view=dotnet-plat-ext-2.1

What are .NET Platform Extensions on docs.microsoft.com?

Suppose I have a class library which I want to target netstandard1.3, but also use `BigInteger`. Here&#39;s a trivial example - the sole source file is `Adder.cs`:

&lt;!-- language: c# --&gt;

    using System;
    using System.Numerics;
    
    namespace Calculator
    {
        public class Adder
        {
            public static BigInteger Add(int x, int y)
                =&gt; new BigInteger(x) + new BigInteger(y);            
        }
    }

Back in the world of `project.json`, I would target `netstandard1.3` in the `frameworks` section, and have an explicit dependency on `System.Runtime.Numerics`, e.g. version 4.0.1. The nuget package I create will list just that dependency.

In the brave new world of csproj-based dotnet tooling (I&#39;m using v1.0.1 of the command-line tools) there&#39;s an [implicit metapackage package reference](https://github.com/dotnet/core/blob/master/release-notes/1.0/sdk/1.0-rc3-implicit-package-refs.md) to `NETStandard.Library 1.6.1` when targeting `netstandard1.3`. This means that my project file is really small, because it doesn&#39;t need the explicit dependency:

&lt;!-- language: xml --&gt;

    &lt;Project Sdk=&quot;Microsoft.NET.Sdk&quot;&gt;
      &lt;PropertyGroup&gt;
        &lt;TargetFramework&gt;netstandard1.3&lt;/TargetFramework&gt;
      &lt;/PropertyGroup&gt;
    &lt;/Project&gt;

... but the nuget package produced has a dependency on `NETStandard.Library`, which suggests that in order to use my small library, you need *everything* there.

It turns out I can disable that functionality using `DisableImplicitFrameworkReferences`, then add in the dependency manually again:

&lt;!-- language: xml --&gt;

    &lt;Project Sdk=&quot;Microsoft.NET.Sdk&quot;&gt;    
      &lt;PropertyGroup&gt;
        &lt;TargetFramework&gt;netstandard1.3&lt;/TargetFramework&gt;
        &lt;DisableImplicitFrameworkReferences&gt;true&lt;/DisableImplicitFrameworkReferences&gt;
      &lt;/PropertyGroup&gt;
      
      &lt;ItemGroup&gt;
        &lt;PackageReference Include=&quot;System.Runtime.Numerics&quot; Version=&quot;4.0.1&quot; /&gt;
      &lt;/ItemGroup&gt;    
    &lt;/Project&gt;

Now my NuGet package says exactly what it depends on. Intuitively, this feels like a &quot;leaner&quot; package.

So what&#39;s the exact difference for a consumer of my library? If someone tries to use it in a UWP application, does the second, &quot;trimmed&quot; form of dependencies mean that the resulting application will be smaller?

By not documenting `DisableImplicitFrameworkReferences` clearly (as far as I&#39;ve seen; I read about it [in an issue][1]) and by making the implicit dependency the default when creating a project, Microsoft are *encouraging* users to just depend on the metapackage - but how can I be sure that doesn&#39;t have disadvantages when I&#39;m producing a class library package?

  [1]: https://github.com/dotnet/sdk/issues/764

What are the application implications of a netstandard library depending on a metapackage?

I have a .NET Standard 1.4 class library that references the System.ComponentModel.Annotations (4.3.0) NuGet package.

I&#39;m then referencing this class library from a .NET Framework 4.6.2 test project. It builds fine, but at runtime I get the following error:

&gt; System.IO.FileLoadException occurred   HResult=0x80131040  
&gt; Message=**Could not load file or assembly
&gt; &#39;System.ComponentModel.Annotations, Version=4.1.0.0, Culture=neutral,
&gt; PublicKeyToken=b03f5f7f11d50a3a&#39;** or one of its dependencies. The
&gt; located assembly&#39;s manifest definition does not match the assembly
&gt; reference. (Exception from HRESULT: 0x80131040)

I tried adding a reference to the System.ComponentModel.Annotations (4.3.0) NuGet package from the net462 project, but that didn&#39;t make any difference.

I tried adding a reference to the .NET Standard library from the net462 project, but still no luck.

Am I missing something here? Is this a known bug, if so is there a work around?

Any help is much appreciated!



Could not load file or assembly &#39;System.ComponentModel.Annotations, Version=4.1.0.0

Is there a way to easily convert a class library targeting .NET Core 2.0 to .NET Standard?

If I understand it correctly, if one wants to maximize the reusability of class libraries in projects targeting different .NET frameworks e.g. .NET Framework, .NET Core, Xamarin, etc., it&#39;s a better idea to target .NET Standard -- provided that all the required APIs are available in the version of .NET Standard that will be targeted.

This is the reason why I want to convert my class libraries from .NET Core 2.0 to .NET Standard 1.6 or .NET Standard 2.0.

Convert .NET Core 2.0 class libraries to .NET Standard

In .NET Core and .NET Standard projects, if you put files and folders within the project directory, they are automatically picked up by Visual Studio; essentially they are part of the project.

What if I have files/folders in there that aren&#39;t really part of the project itself (in terms of code or content) - short of removing them altogether, is there a way I can exclude them from the project as I can with projects targeting the full .NET Framework?

All .Net Standard Solutions on Gang of Coders

Total of 16 .Net Standard Solutions

Can't use System.Configuration.Configuration manager in a .NET Standard2.0 library on .NET FX4.6