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.
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.
How is this more efficient than creating an xml config and just parsing it? Is it wrong to implement a ConfigParser helper class to read the input values of an .xml file? The user secrets part was very useful however
The Appsettings system can actually read xml files as well. That means you don't need to implement a parser in order to use XML files if you really want them. While this system primarily uses JSON, it isn't actually tied to JSON. It also pulls from environment variables, from command line parameters, and from other systems like the settings in Azure Web Apps.
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: ruclips.net/video/oXNslgIXIbQ/видео.htmlsi=7-UJU4veBhGTNzvK
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.
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.
Secrets.json is just for local development. When you deploy to a virtual machine, you would put that data in appsettings.json. Secrets.json is no more secure than appsettings.json. If you have access to the machine, you have access to the secrets. When you deploy your application to a virtual machine, update the appsettings.json data with the correct information for that virtual machine.
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.
@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
@@IAmTimCorey By the way: how would you manage user preferences in a console app? The appsettings.json "approach" seem to be kind of read-only focused.
User preferences are better stored in a local data store of some type. For example, if you are using a web app, I would use LocalStorage. If you are using a desktop app, maybe a separate JSON file or a SQLite database.
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 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.
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.
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.
@@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.
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.
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 RUclips content about this is all about web apps. And even if that follow-up does not happen, thank you for all your work!
I covered that in this video: ruclips.net/video/rFncI9yfY-E/видео.htmlsi=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.
But that's just it - you aren't just reading a json file. In web apps by default you are reading from five different places - appsettings.json, appsettings.development.json (or release), secrets.json, environment variables, and command line arguments. That's the default. Then you add in Azure App Settings and Azure Key Vault as a couple of the options, especially for production. There are LOTS more options that you can add. For instance, by default .NET also reads from app.config/web.config if your project has been upgraded from the .NET Framework. Each of these options has a specific use-case and value. For instance, secrets.json is incredibly useful for local, workstation-specific settings that you don't want put into source control. Environment variables are great for machine-specific configurations (especially in production). Key Vault is great for providing secret values that even the developers don't have access to, especially in production. All of this flexibility is even more valuable when you look at doing transformations during the CI/CD process. If you are building a tiny app as a solo developer with a manual build process, yes, you might not need all of this. However, if you are working on a team, if you are working with a moderately-sized application, if you are working with a CI/CD system, or if you are working in a business environment, these additional features are really important.
@@IAmTimCorey Thank you for your detailed response. You're right, I think I was a bit frustrated because we recently started working with .NET 8 while most of our work up until now was done in .NET Framework 4.7. Additionally, we've also been using Azure more extensively, including the Key Vault. When you've been a C# developer for 20 years and have had to discard a significant portion of your knowledge every few years because Microsoft decided to change everything again, it can be frustrating at times. Your video was really helpful and in the end, I managed to accomplish everything I wanted to, except for the Key Vault part, which I’m currently working on. I’ve also given you a 'like' and 'follow' because I think I can learn even more from you. Good luck with your channel!
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.
@@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.
@@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. :)
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.
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
I was literally looking into this last week. Another bookmark.
Great!
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.
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/
Thank you Master, this is a great improvement for our console applications
You are welcome.
Thanks, your lessons are amazing
You are welcome.
Many thanks for this valuable video.
You are welcome.
Thanks for sharing. Very useful!
You are welcome.
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.
Very useful. Thank you for sharing
You are welcome.
just what i needed. thank you
Great!
How is this more efficient than creating an xml config and just parsing it? Is it wrong to implement a ConfigParser helper class to read the input values of an .xml file? The user secrets part was very useful however
The Appsettings system can actually read xml files as well. That means you don't need to implement a parser in order to use XML files if you really want them. While this system primarily uses JSON, it isn't actually tied to JSON. It also pulls from environment variables, from command line parameters, and from other systems like the settings in Azure Web Apps.
Thank you Tim. Could you also explain how to use this appsettings.json file to configure a new ILogger in that console application?
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: ruclips.net/video/oXNslgIXIbQ/видео.htmlsi=7-UJU4veBhGTNzvK
We use this all the time. But you have to be sure that your whole team understands it and does it the same way.
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.
Just starting this . Hope this works with forms app as well?
Yes, you can access settings in a Forms app.
Pretty cool! Thank you!
You are welcome.
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.
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.
Is this possible to deploy to virtual machines and still get access to secret? Or is it just for local development?
Secrets.json is just for local development. When you deploy to a virtual machine, you would put that data in appsettings.json. Secrets.json is no more secure than appsettings.json. If you have access to the machine, you have access to the secrets. When you deploy your application to a virtual machine, update the appsettings.json data with the correct information for that virtual machine.
What we need to deploy the app? Where those json files will be created/copied? Great video but this is not clear
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.
@@IAmTimCorey thanks. But the "secrets" file?
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.
@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
@@IAmTimCorey look like this stuff Is suitable only for APIs. Desktop applications have differenti requiremnts
(Another) Great video!
I'm glad!
@@IAmTimCorey By the way: how would you manage user preferences in a console app? The appsettings.json "approach" seem to be kind of read-only focused.
User preferences are better stored in a local data store of some type. For example, if you are using a web app, I would use LocalStorage. If you are using a desktop app, maybe a separate JSON file or a SQLite database.
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?
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.
@@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.
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.
the same question, I'm also very curious about this
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.
@@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.
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.
@@IAmTimCorey Thank you very much for the clarification and explanation.
Is there a way to "Alter" the settings as well as read them in code?
Yes, I believe you can index your value and then set it something like configuration["MyValue"] = "Test";
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 RUclips content about this is all about web apps.
And even if that follow-up does not happen, thank you for all your work!
I covered that in this video: ruclips.net/video/rFncI9yfY-E/видео.htmlsi=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.
What happened to the postman clone series? I believe there hasn’t been an update in a long while.
It is over
At the end of the last video, I let you know it was the last video and what I recommended you do next.
@@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
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.
I wish this video was released last week 😂
I get that a lot.
Source code link is broken.
I'm working on the source code download system. I'm tracking down a bug related to rotating the password.
So much work and packages for reading a json file, ridiculous.
But that's just it - you aren't just reading a json file. In web apps by default you are reading from five different places - appsettings.json, appsettings.development.json (or release), secrets.json, environment variables, and command line arguments. That's the default. Then you add in Azure App Settings and Azure Key Vault as a couple of the options, especially for production. There are LOTS more options that you can add. For instance, by default .NET also reads from app.config/web.config if your project has been upgraded from the .NET Framework.
Each of these options has a specific use-case and value. For instance, secrets.json is incredibly useful for local, workstation-specific settings that you don't want put into source control. Environment variables are great for machine-specific configurations (especially in production). Key Vault is great for providing secret values that even the developers don't have access to, especially in production.
All of this flexibility is even more valuable when you look at doing transformations during the CI/CD process.
If you are building a tiny app as a solo developer with a manual build process, yes, you might not need all of this. However, if you are working on a team, if you are working with a moderately-sized application, if you are working with a CI/CD system, or if you are working in a business environment, these additional features are really important.
@@IAmTimCorey Thank you for your detailed response. You're right, I think I was a bit frustrated because we recently started working with .NET 8 while most of our work up until now was done in .NET Framework 4.7. Additionally, we've also been using Azure more extensively, including the Key Vault. When you've been a C# developer for 20 years and have had to discard a significant portion of your knowledge every few years because Microsoft decided to change everything again, it can be frustrating at times.
Your video was really helpful and in the end, I managed to accomplish everything I wanted to, except for the Key Vault part, which I’m currently working on. I’ve also given you a 'like' and 'follow' because I think I can learn even more from you. Good luck with your channel!
Is it just me or is Microsoft constantly trying to reinvent the wheel?
Could you elaborate on what you mean?
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.
@@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.
@@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. :)
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.
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
Thanks! I'm working on the source code download system. I'm tracking down a bug related to rotating the password.
@@IAmTimCorey
Thank you Tim!