Accessing AppSettings in Console Apps Including Secrets.json

Console apps are incredibly useful. From running simple applications to executing automated tasks, Console apps are a really valuable application type. However, they don't come with any existing code, which means you need to build out anything you want. One common feature developers end up wanting is access to a settings file. In this video, I am going to show you how to add an appsettings.json file and a user secrets file to your console app. We will go over how to set it up, how to access the data inside of it, and what the best practices are around using these files.
Full Training Courses: IAmTimCorey.com
Source Code: leadmagnets.app/?Resource=App...

[@AldoInza]

I was literally looking into this last week. Another bookmark.

[@IAmTimCorey]

Great!

[@danielhuber2936]

Thanks for sharing. Very useful!

[@IAmTimCorey]

You are welcome.

[@arashsafi525]

Thanks, your lessons are amazing

[@IAmTimCorey]

You are welcome.

[@christianimfeld7357]

Many thanks for this valuable video.

[@IAmTimCorey]

You are welcome.

[@andergarcia1115]

Thank you Master, this is a great improvement for our console applications

[@IAmTimCorey]

You are welcome.

[@demariners]

As always, super useful! Thank you for what you do! I have been looking and I am not sure if you have done this already, but please consider doing a video on Source Control. Specifically within VS and explaining how to do the more advanced stuff such as cherry picking, rebasing, and stashing. It has always been so confusing for me within VS.

[@IAmTimCorey]

Thanks for the suggestion. Please add it to the list on the suggestion site so others can vote on it as well: suggestions.iamtimcorey.com/

[@rodrigoalves8554]

Pretty cool! Thank you!

[@IAmTimCorey]

You are welcome.

[@axeldev7199]

Very useful. Thank you for sharing

[@IAmTimCorey]

You are welcome.

[@michi1106]

rly love your videos. In addition to this content. I start to use these settings to store my configuration, but there is a big issue that you may sshow/say to others as well. It's readonly. So for my WinForms- Practice-Program, not so useful. But i found a very useful hint on stackoverflow. Just as you show before, it's possible to add mutliple-files to the configuration during the build. So i just add a second "appsettings.json"-file to the configuration, like this "configuration.AddJsonFile(Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData), ProductName, "appsettings.json"), optional: true, reloadOnChange: true);" Then i designed a settings-class for serilisation. Stored the changed values there and save the file at the end. And with a new start, the configuration-builder merged the 2 settings-files and i can use the normal configuraion-handling. So maybe someone else, find this helpful.

[@OldGuyAdventure]

Been working on a rework for machine event software and have been planning how to move it to C# as a service. It has settings that it needs to use to verify certain conditions exist with specific machines and valves.

[@IAmTimCorey]

If you are looking to create a service, check out the Worker Service project type. It runs as a Console app for testing but then installs as a service (or daemon on Mac/Linux). It has appsettings, dependency injection, and more built-in.

[@kidservice]

Thank you Tim. Could you also explain how to use this appsettings.json file to configure a new ILogger in that console application?

[@IAmTimCorey]

This video is using .NET Core 3.0, but the principles still apply. It covers how to set up logging, including how to use appsettings for your logging: kzbin.info/www/bejne/pYmxpJ-dfr18mLMsi=7-UJU4veBhGTNzvK

[@PGWalkthrough]

great video, i just have a question, when you working in a team and each developer use the secret file, does this mean that each developer secret file guid will be added to the project? how to maintain those guids? lets say you have 10 developers and maybe some people left the company, do you have to delete the guids for the developers that left from project file?

[@IAmTimCorey]

Once the GUID is set, everyone uses that same GUID. Since the likelihood of it already being in use is infinitesimally small, it isn’t a problem.

[@PGWalkthrough]

@@IAmTimCorey Thanks for the quick reply. I think we did that eventually. just note every time a new developer press on manage user secrets it creates a new user secret file for them. so we had to manually update the user secret file name to be the same as the existing guid then remove the reference to the new guid from the project file.

[@alexlo5655]

Hi Tim, Thank you for the Video. You didn't mentioned in your video what will happen when the code will be pushed to PROD. How the secretes will be accessed? from Production.apsettings.json, which is revealing the secrets? Should this be elaborated? I believe the code which reads from some "secret" vault should be added.

[@VuongoanPro]

the same question, I'm also very curious about this

[@donaldlee6760]

Another same question, specifically if hosted in a Google Cloud Windows VM as is pretty common. I assume the answer is most often a Windows environment variable because the Windows server admins are typically OK to know the secret. If the server admins are not authorized to see the secret then I'm at a loss of what options to consider. I really don't want to overcomplicate the solution by adding an Azure keyvault because organizations that use Google cloud are unlikely to also use Azure.

[@alexlo5655]

@@donaldlee6760 My personal opinion - you have to have a service which reads the secret key. And depends on environment and settings you have to register it in DI and it will produce you the key either from the secrets location in you PC or from Azure or from Google Cloud, etc.. My personal opinion that this should be presented in this video.

[@IAmTimCorey]

I talked about this briefly in the video. If, for instance, you deploy to Azure, you would use the Environment Variables in Azure to store your secret information. Other cloud providers typically have something similar. If, however, you are deploying to a full server (not a hosted web app or serverless solution), you would put your secrets right in the appsettings.json when you publish to the server. Not in source control, but when the CI/CD process publishes your application to the server, it would update the produced appsettings.json file with the secret information. This is because you should trust the server you deploy to and it should have restricted access. If it does not, your information is not secure. It does not matter if you use environment variables, secret keys, encrypted values, etc. If a user has control over the machine that is running the executable, they can see your information in clear text no matter what you do. This answers @donaldlee6760's question as well - if you don't trust the server admins, they should not be server admins. If they are an admin, they have access to see your secrets. All of them. The secrets.json file is only for local development. Its purpose is to keep secrets out of source control. That is it. There is no equivalent for the deployed location. You use appsettings.json to store your secret information once it gets to the server (again, by updating it via CI/CD) or you put that information in environment variables if you deploy to a cloud provider.

[@alexlo5655]

@@IAmTimCorey Thank you very much for the clarification and explanation.

[@tabhorian]

We use this all the time. But you have to be sure that your whole team understands it and does it the same way.

[@IAmTimCorey]

Yep, that's part of the team dynamic - establishing how you are going to do things in a similar manner in order to have consistency in your code base.

[@demariners]

Is there a way to "Alter" the settings as well as read them in code?

[@jamesbest3347]

Yes, I believe you can index your value and then set it something like configuration["MyValue"] = "Test";

[@rolphkeune]

Hi Tim, are you going to do a follow up to this video? One that explains where you should store the password if you create a win application (not web) and then want to connect correctly to an (Azure) SQL database: 1.Using SQL authentication. (I find this difficult because the db key or the encryption key are obviously not allowed to be stored in/with the app... but if you store it in, for example, the Azure key vault, how does the authentication take place? Where does that 'key' come from?) 2.Using Window authentication 3. Using the Azure key vault 4. Without using the Azure key vault (alternative solutions) It would personally help me a lot if there was a follow-up because the most recent KZbin content about this is all about web apps. And even if that follow-up does not happen, thank you for all your work!

[@IAmTimCorey]

I covered that in this video: kzbin.info/www/bejne/qHfRlHxvrsuMY6csi=kRW8FcNWM7Ej2-rb Basically, desktop applications cannot securely access resources without exposing that access information to the user. The best option is Windows authentication, but that means you are adding each user to your database and managing their permissions. That also means that they can use SSMS to make the same calls they can make through the app (more if you give them too broad of permissions). Storing credentials in Key Vault won't help because the app has to download and decode those connection strings in the app itself. Since the user has access to the app and the memory, they have access to the password. Yes, it can be harder to access than just reading a text file, but that is only a small hurdle. It causes a false sense of security. The same is true with encryption in appsettings. Yes, you can't read it directly, but the app can so again, the user has access to the clear-text password. That information is also transmitted then to SQL, which means the user can read their own network traffic (and since they own one end of the connection, SSL doesn't help here). The best option is to have the desktop app call an API if it needs secure access. This greatly reduces the attack footprint and it allows you to conditionally allow limited access rather than giving access all of the time.

[@valhallagalex]

What happened to the postman clone series? I believe there hasn’t been an update in a long while.

[@iasonmax3473]

It is over

[@IAmTimCorey]

At the end of the last video, I let you know it was the last video and what I recommended you do next.

[@valhallagalex]

@@IAmTimCorey my mistake. I was waiting for it to be done before I started. Your series were longer in the past. Appreciate your work regardless

[@IAmTimCorey]

Ah, gotcha. Yeah, this one was a short one. I may add to it in the future. We will see. For now, it is concluded though.

[@liber_channel]

What we need to deploy the app? Where those json files will be created/copied? Great video but this is not clear

[@IAmTimCorey]

If you deploy the app, you would deploy the appsettings.json file with the app. That's why we said it needed to be copied if newer. That copies it to the output directory. Secrets is just for your machine. When your app is deployed, you would either update the appsettings.json of the built file with the secrets it needs or you would update the environment variables if you deployed your app to a cloud service.

[@liber_channel]

@@IAmTimCorey thanks. But the "secrets" file?

[@IAmTimCorey]

That’s just for your machine. It is information that you use for local testing. In production you don’t need it because appsettings works just fine.

[@lancecodes]

@iamtimcorey do you have a video on how to deploy your app server blazor app and connect to a database ? I’m having trouble getting my app server instance to recognize the environment variables properly for some reason

[@liber_channel]

@@IAmTimCorey look like this stuff Is suitable only for APIs. Desktop applications have differenti requiremnts

[@sirrexos1596]

I wish this video was released last week 😂

[@IAmTimCorey]

I get that a lot.

[@alexlo5655]

Source code link is broken.

[@IAmTimCorey]

I'm working on the source code download system. I'm tracking down a bug related to rotating the password.

[@W4L3YT]

Is it just me or is Microsoft constantly trying to reinvent the wheel?

[@ByronScottJones]

Could you elaborate on what you mean?

[@IAmTimCorey]

I'm not sure what you mean. Do you mean because there is a "new" way of accessing settings compared to what they used with the .NET Framework? If so then yes, like all developers, they are looking to improve on what they have done in the past. Instead of utilizing the slow, clunky system they had, they upgraded to an incredibly powerful new system that is flexible and much, much faster.

[@W4L3YT]

@@ByronScottJones There are too many ways to create and access configuration files. I am not complaining about it. But there seems to be a "hey, let's come up with a new way to do that" mentality going on. There are App.config (or Web.config) and Settings.settings. Now there are launchSettings.json and appsetings.json.

[@W4L3YT]

​@@IAmTimCorey Yes, that is what I mean. If this new way of accessing the settings files is faster than previous iterations, then I am OK with it. However, upon initial usage, it seemed unnecessary and convoluted. I like to keep things simple. :)

[@IAmTimCorey]

It is definitely faster. It is also MUCH more flexible. The old system required app.config/web.config and it did not handle overrides very well (thus tools like Slow Cheetah). This system is modular, meaning you can bring in five different sources "out of the box" by default in ASP.NET Core (appsettings, developer/release settings, secrets, environment variables, and command line arguments). However, you can choose to add more or remove some. In this demo, we built out our own config builder and only added the ones we wanted. We could have also added additional ones like Azure KeyVault very easily. In this system, the control is all in the hands of the developer rather than Microsoft forcing you to use one system in one way.

[@jesusdelarua5995]

As always, Great course! Thank you Tim! I cannot access source code :( Error. An error occurred while processing your request. Request ID: 40002868-0000-c400-b63f-84710c7967bb

[@IAmTimCorey]

Thanks! I'm working on the source code download system. I'm tracking down a bug related to rotating the password.

[@jesusdelarua5995]

@@IAmTimCorey Thank you Tim!