Core: .Net Core Class Library and Associated Settings

[truunk]

I am starting to work with .Net core and i am struggling to follow tutorials etc because it seems as though the framework has moved on even though some of the tutorials a just a few months old. One area were i am completely befuddled is class libraries but i am not sure if its a language misunderstanding, and tooling one or a bit of both.

Class Libraries

I have downloaded VS2017 RC (Community) to start working on this and i want to create a class library to contain data access logic for example, but visual studio only allows me to create a .Net Standard class library, so i am not sure if my VS install is busted and i should get both (Core and Standard Class Library Templates).

The Standard Template (which at first i thought meant ASP.Net not Core) i now understand to be the cross platform setup. Issue i have is it doesn't seem to correlate to any examples that i have seen, i.e. it has a dependencies item in the file-list but does not contain a projects.json for example, which pretty much all examples show as a route to manage dependencies, tooling etc.

What am i missing here, has the .Net Core class library been superseded by the .Net standard class library, does the .Net standard library not require a projects.json or should i create one anyway? and is my templates install busted on visual studio 2017?

I really love the direction this is going, but my brain can't keep up with the switch in language/names (Core, Standard etc) and choices that occur in such a short amount of time and i would really appreciate some clarity on what i should be utilising moving forwards.

Associated Settings for Class Libraries

I can see some threads on here already pertaining to the demise of the app.config, but how could we create a class library that is self contained with regards to settings, do we, as i have seen some examples of have to turn it into an "App" of some sort so we can access to the Setup classes/Methods (via a program.cs for example) to be able read in a configuration file for that specific class library, is that the approach at the moment?

[Petermarcu]

@truunk , thanks for the feedback. I've passed it on to the folks working on the template story.

The ultimate goal is to have a single library template that then gives you options on what you want it to be. In VS 2017, it probably wont get all the way there. In VS 2017 and beyond, project.json is gone. You do all your dependency references directly in your csproj file.

@JeremyKuhne, Is working through Configuration/Settings as we speak. He is probably in a good position to give guidance on class library setting.

[richlander]

Great feedback and I sympathize.

We made the decision to keep the .NET Core docs focused on project.json until Visual Studio 2017 ships its final release. The latest release is a release candidate, at the time of writing. Once VS 2017 ships, this situation will be much more straightforward.

Apologies for the confusion and thanks for taking the time to write the issue.

[JeremyKuhne]

@truunk If you're already using System.Configuration for library/app settings you'll be able to use System.Configuration.ConfigurationManager to continue to do so cross framework (we needed to name the assembly differently from NetFX to allow running against it, 99% of System.Configuration is there).

As you've noted, we haven't provided guidance on how to deploy settings in Core- we don't use System.Configuration ourselves. While we didn't have the library in CoreFX until now, we're unlikely to use it. The key reasons for that is that System.Configuration brings in a lot of dependencies (heavy) and those dependencies need the ability to read settings (notably XML).

While we don't use them internally, config files are a pattern that is fairly well understood and can continue to be used. While it isn't part of the official .NET Standard 2.0 it is fully cross plat outside of the built-in encrypted Protected Sections (which is a bit obscure).

We're definitely interested in your continued thoughts on the matter and will try to come up with some clear guidance.

[truunk]

@JeremyKuhne Thanks for the reply. At this moment i am not using anything, this is a new project. Not being the biggest fan of System.Configuration anyway and as you say kinda defeats the purpose of the clean architecture of Core.

Maybe its better to outline the scenario as it may give some indication into what i am doing and why. The application i am building will have a few clients (Web, API etc) and as such will share boundaries such as data, databases etc, but in my scenario the entry point into the data classes for example will not be the same, so Web will be a standalone application, the API endpoints will be standalone to power other clients such as mobile, and at that point we have multiple entry points into the data classes where i will probably have to define items such as the connection strings etc as configuration elements on the top end projects (Web, API) which is fine, but obviously means that i might multiple configuration files for the same thing, instead of containing it all in the Data class library and having it in one place.

The way settings are applied in the startup.cs is a great API (i.e. loading a configuration file via the builder), not sure if that would work in a class library without some form of entry point/bootstrapper (i have seen program.cs be used and the project converted to a console app to similar things) so the process may not work here.

Thinking out loud, could ConfigurationBuilder be used in a class library via constructor of method? so for example, in my data scenario, instead of my startup.cs instantiating a DbContext directly it is abstracted into a DbContextFactory that uses Configuration Builder to load a configuration set out by the class library, or is that pie in the sky stuff?

[JeremyKuhne]

I'm not familiar with those classes- you're probably better off moving the discussion to https://github.com/aspnet/Configuration. Please tag me- I'll follow along and try and rationalize how the old config model fits in.

[Petermarcu]

I believe all the feedback has been heard from this issue and plans are in place to address it. Thanks @truunk . I'm going to close this issue now. If the new docs come out and there is still confusion, lets open new issues so we can get fixes tracked for those.