[Proposal] A using statemnt for settings files to generate strongly typed settings

[VBAndCs]

I suggest to add an easy way to import settings files (json and xml) as a strongly types objects, like this:

using MySettings = "mysettings.json";

Or:

Imports MySettings = "mysettings.xml";

Note that quoting the file name prevents any ambiguity with namespaces.

Implementation:

1. Roslyn can parse the setting file, generate the necessary classes to represent its structure, and add static/shared fields in these classes to hold the setting values.

2. To prevent naming conflictions between classes generated from multiple settings files, classes can be added to a name space based on the file path and name, such as:
   namespace mysettings.json
namespace config.mysettings.xml

3. The using statement can appear at many files, but of course the strongly typed settings will be generated once for the same file, and used from anywhere.

4. At each build, the last modified date of the setting file should be checked to update the generated classes if necessary.

This way, we just add a single line of code at top of the file to have access to the settings with intelligence support.

[YairHalberstadt]

This is a language feature and so should be requested at the relevant repositories for C# and VB

[VBAndCs]

@YairHalberstadt
It can be done in Roslyn to generate the classes and convert the Using statement to a normal using static statement to reference them, so Roslyn can deliver a regular code to C#/VB without needing any change in the language it self.

[jmarolf]

@VBAndCs I don't see how this isn't a language feature. You are asking for C# and VB syntax which does not compile today to compile. Interesting idea though

[paul1956]

This has many more uses then just "Settings", I am using Coverlet and had to manually create the class and then populate it with Newtossoft.Json, for XML I have not yet found a very simple solution and if the file format changes I need to manually change the classes. Love the idea, don't care if technically it is a "Roslyn" feature or a language feature or something else it is incredible useful the only question is what is the best way to move it forward.

[CyrusNajmabadi]

it feels like you could trivially write a tool to do this, and not make it part of the language.

Making json part of c# is something i'd be very wary of already. I already had to try to support json strings as part of this work: dotnet/roslyn#24110

It's very non-trivial. For example, there are different rfc specs out there for json. And many tools produce or read broken json. What would be expected of C# here? how would it be spec'ed in terms of what it understood/disallowed?

it is incredible useful the only question is what is the best way to move it forward.

Why don't you write a standalone tool that can take xml or json and produce these files and make it available for anyone who wants to use it?

[VBAndCs]

@jmarolf

I don't see how this isn't a language feature

Suppose I have this mysettings.json file:

"AppSettings":{
  "First" : "Value 1",
  "Second" : "Value 2",
  "Car": {
      "NumberOfDoors" : 5,
      "RegistrationDate" : "2017-01-01T00:00:00.000Z",
      "Color" : "Black"
    }
}

and I used this statement:
using MySettings = "mysettings.json";

This is what Roslyn should do:

1. generate the following code:

    public static class AppSettings
    {
        public static readonly string First = "Value 1";
        public static readonly string Second = "Value 2";
        public static readonly (int NumberOfDoors, DateTime RegistrationDate, string Color) Car = (5, DateTime.Parse("2017-01-01T00:00:00.000Z"), "Black");
    }

2. convert the using statement to:
   using MySettings;

Now, there is nothing new in the code file, and can be delivered to C# compiler as usual. It only contains things like:
Console.WriteLine(AppSettings.Car.Color);

Which is a regular stuff.

Note that if we need to use MySetting namespace, we can use this statement:
using "mysettings.json";
Which direct Roslyn to generate the classes, and should be completely removed in the pre-compiling stage (not removed from the editor of course, because it is still needed to update the classes, which need to compare the last modification date of the setting file with the one of the generated classes).

[VBAndCs]

@jmarolf @paul1956
Thumps up please, because I see thumps down only :)

[VBAndCs]

@CyrusNajmabadi

Why don't you write a standalone tool that can take xml or json and produce these files and make it available for anyone who wants to use it?

I think it can be written as a VS extension, but this will be a very basic tool in ASP.NET Core project that will make using settings file very easy with only one line of code, instead of the current option pattern, where you need to manually build the classes then use the services.Configure to populate them with values.
We can use the most popular json format, that is used in ASP.NET Core projects, and raise exceptions for broken formats.
This is a helpful tool that will benefit millions of user, and this will not happen if I wrote it as a separate package, because only few people will know about!

[YairHalberstadt]

@VBAndCs

Based on your description of how you would like this to work, it sounds like it could be implemented as a code fix.

If so, I would suggest implementing this yourself as a Roslyn code fix. If it proves popular Roslyn might include it in the default set of provided code fixes.

If you need any help implementing it, the Roslyn gitter is a good place to ask for help.

[YairHalberstadt]

I think however, it would be best if you rewrote the issue to make clear you are asking for a code fix, not a language feature - I think I could support this as a code fix, but would be more hesitant about making this part of the language itself.

If one of the people who work on the IDE think this is interesting, they may mark it with the Needs Design Review tag. From there it's a slow process till it will actually get reviewed (the IDE team has a huge backlog), but creating a pull request would likely, but not definitely push it forward faster.

[VBAndCs]

@YairHalberstadt
Nice idea, but the code fix will replace the using statement or erase it completely, which will prevent monitoring the source file to update the classes.

[HaloFour]

All of this can be accomplished today with a custom tool in Visual Studio or MS Build. It's basically a reimplementation of resx files, except in JSON format, which are accomplished via custom tools which emit source. There's no reason for any syntax in C# or VB.NET or for it to be done in Roslyn.

[VBAndCs]

@YairHalberstadt
It can also be done by adding a new VS context menu command to motor the json file and generate updated versions of the strongly typed classes at each build.

[HaloFour]

For reference:

https://docs.microsoft.com/en-us/visualstudio/extensibility/internals/custom-tools?view=vs-2019

Custom tools let you associate a tool with an item in a project and run that tool whenever the file is saved. Certain custom tools, sometimes referred to as single-file generators, are frequently used to implement translators that generate code from data and vice versa.

[VBAndCs]

@HaloFour
I agree, and I would build the tool myself even as an external one, but as I said, I find it helpful for many developers, so I hope VS adapt it in any suitable way.
Tanks

[CyrusNajmabadi]

I really don't understand the purpose of this. You can already use .settings files like so:

This is just simple xml like so:

This already generates the necessary classes and whatnot for you. And that means that things like intellisense works:

So why do we need another way to do something that is already supported and has been in VS for something like 15+ years?

[CyrusNajmabadi]

I agree, and I would build the tool myself even as an external one, but as I said, I find it helpful for many developers, so I hope VS adapt it in any suitable way.

But VS already has this. It's been supported for probably 2 decades now. Why do we need another feature that duplicates what is already there?

[paul1956]

@CyrusNajmabadi because today it is only for one specific file. If I could use any XML file (and maybe I can and don't know it) it would solve the XML issue, and the same issue applies for JSON. From reading this it looks like it could be a utility to convert format to class source file, and a way to integrate the utility into VS so that when the file changes the class changes. Maybe the ability to do both those things exist today and if so then an example or documentation is "all" that is needed.

[CyrusNajmabadi]

@CyrusNajmabadi because today it is only for one specific file.

I'm not sure i understand what that means.

If I could use any XML file (and maybe I can and don't know it) it would solve the XML issue, and the same issue applies for JSON

You could certainly write a tool like this to solve that problem. You don't need the language to do anything.

Maybe the ability to do both those things exist today

THat seems to be the case.

and if so then an example or documentation is "all" that is needed.

See: https://docs.microsoft.com/en-us/visualstudio/extensibility/internals/implementing-single-file-generators?view=vs-2019

This issue can likely be closed.

[VBAndCs]

@CyrusNajmabadi

1. The old settings system doesn't generate types. It only generates properties to hold values of pre-defined types.

2. Many things have been changed in 15 years, and now ASP.NET Core embraces JSON files.

3. VS.NET offers a lot of tools most of them are not important to many developers and never use them. It will be better if VS offers a more time saving tools, especially those for generating classes used for strongly typing. I have been asking for this in many other cases such as pre-defend dictionary keys and dynamic properties.

4. Roslyn is out there, and if can do wonders and save half developers life spent in writing trivial codes again and again.

Note:
I hope you open a VS.NET repo here so you can move there issues that doesn't fit Roslyn, instead of manually republishing them on user voice or whatever.

[CyrusNajmabadi]

The old settings system doesn't generate types. It only generates properties to hold values of pre-defined types.

So write a single-file-generator that generates types...

Many things have been changed in 15 years, and now ASP.NET Core embraces JSON files.

So write a single-file-generator that supports json. Or just use xml.

VS.NET offers a lot of tools most of them are not important to many developers and never use them. It will be better if VS offers a more time saving tools, especially those for generating classes used for strongly typing.

So write such a tool for vs.net. You can then make it available as an extension to benefit other people.

I hope you open a VS.NET repo here so you can move there issues that doesn't fit Roslyn, instead of manually republishing them on user voice or whatever.

This does not appear to be a vs.net issue. As already explained several times, VS already has support through this. Either by using the existing .settings system (which seems to be totally sufficient for your use case, you jsut refuse to use xml for some reason), or by writing a single-file-generator.

The feature and extensibility is already there. So... just use it...

[CyrusNajmabadi]

As before, i think this issue can be closed. It has nothing to do with roslyn. And all the capabilities you want are things you can either use already, or you can spend an hour and implement. I don't think VS needs to incorporate something you can just whip up without much trouble if you would truly find value in it.

Please move this to uservoice if you really do want VS to take it. There, others can vote on it. If it's sufficiently voted on (which i doubt, but might happen), then VS can take it. If it doen't get voted on, then i would, again, strongly suggest this be something you make happen since it's highly unlikely anyone is going to do it for you.

[VBAndCs]

There are online sites to build classes from JSON, but doesn't populate them with values (ASP>NET core can provide this step). This is good, but still time consuming. Such a capability must be a VS built-in.

Try this http://json2csharp.com/
and this https://app.quicktype.io/#l=cs&r=json2csharp
but enclose the entire JSON in {}

[CyrusNajmabadi]

Such a capability must be a VS built-in.

Why? If it's so critical than why are only two people asking for it?

[HaloFour]

This seems like an excellent use case for source generators, effectively a form of type providers.

[alrz]

strongly typed settings

aspnetcore already solved this problem with IOptions<T>, although you have to declare T yourself.

Moreover, the lack of generators feature shouldn't stop you from automating the code generation, you could just write a tool to generate it for you, and if necessary, have it run somewhere along the build pipeline.

[CyrusNajmabadi]

Moreover, the lack of generators feature shouldn't stop you from automating the code generation

Not only that, but this truly is an area that is already supported by the .net ecosystem. We already have several examples of cases where you start with data in some other form (like .settings or .resx) and the build process generates the surrounding code for you to interact with it in a typesafe and error-free manner.

The only difference here that i can see is that @VBAndCs seems to want this for json (which is entirely reasonable). But i don't know why you need a language feature here. Just do what has been done for things like xml. It's really not hard at all. Heck, maybe someone has already felt the need to scratch this itch and has done it already.

[VBAndCs]

Surprise :
ASP.NET Core bodies told me that VS.NET already translates JSON to classes, using the Edit/Paste Special menue, and it works for both C# and VB.NET:
https://user-images.githubusercontent.com/4734691/63812279-bb2b9000-c8de-11e9-86a9-897ef2e24d30.png
This can be built on to make the feature I suggested. I will send this to user voice.

[gulshan]

I think my proposal #1614 tried to address similar concerns in a different manner.