Відео

Thank you.

You are welcome.

The same way you get the first child form. You specify what each form depends on in the constructor. When DI goes to satisfy the main form, it will see that it needs a child form. When it goes to provide the child form, it will see that the child form depends on a child form of its own. It will get the grandchild form first and work its way up the chain.

@@IAmTimCorey and if creation require dynamic data?

You would set up a factory in you DI system or pass in the data after creation of the generic class instance.

Thanks!

This is a rather bad misconception. The issue is not C#/.NET. The issue is that Visual Studio does so much, but it requires so much power. For instance, I have a Raspberry Pi keyboard Computer (full computer in a compact keyboard). It barely runs anything because it has a 1.8 GHz processor and 4GB of RAM. I have it running VS Code with the C# plug-in. I've built and run full Blazor apps on that computer. So no, you don't need a massive computer to build and run .NET applications. Yes, Visual Studio does take up a lot of space and a lot of power, but that's because it is a full IDE running AI tools and has all of the Intellisense/Intellicode/etc. features that are constantly running to make you as efficient as possible as a developer. If you need to develop .NET projects, but are struggling to get a computer that runs Visual Studio well, check out VS Code and the C# Dev Kit. You can use even really old hardware running a free version of Linux and get a lot of power out of it.

The purpose of user secrets is to ensure that secrets don't accidentally get out. Adding a file to your project, ensuring it is in the gitignore, and making sure no one accidentally uploads it is a lot harder than just using the existing system that just works. As for sharing those secrets, you don't. That's the point. They are just for you on your machine. Even a different machine will probably have different secrets. Typically, you use user secrets for storing your local SQL database, etc. When another user wants to spin up a development machine, they either use the defaults from appsettings.json or they create their own secrets file. That's why I create the blank entries in appsettings.json. That way you know what settings need to be added to secrets.

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.

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/

Not strictly necessary, but it is really helpful.

I get that a lot.

Thanks for sharing!

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.

Great!

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.

All rules have exceptions and best practices don't even rise to the level of rules. Developers need to be discerning about what they do and why they do it.

I'm not sure what you mean "start the console app from another directory". I've not had a problem with GetCurrentDirectory. Are you saying that when you run the exe, it doesn't detect where the exe is?

@@IAmTimCorey So for example, let's say your app is in c:\myapps\mycookingapp\cooking.exe. And then you cd into the root c:\, and run "myapps\mycookingapp\cooking.exe" from the command line. In this case GetCurrentDirectory will return "c:\". Or another example, you put your app's directory into the PATH and execute from any random directory. GetCurrentDirectory will return whatever directory you are currently in.

Ah, I see. Thanks for sharing!

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.

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.

The reason you could do that in the .NET Framework was because it included everything in the framework. That was terribly expensive and wasted a lot of space. Yes, it is a bit more complex to add a NuGet package, but it also makes our applications more efficient.

@IAmTimCorey I did hear you say that in the video, but again, that goes to my point. I'm not developing cross platform, for-profit, multi-developer solutions. I'm creating a powershell cmdlet that needs to run on a windows server for a set of tasks required for an I external application. By forcing me into a methodology that is intended to allow for portability, multi-platform, multi-developer solutions, it just keeps me from creating the tools I need. Nuget is fine when you need to extend the library, but if all you need is the stuff built in to the OS via framework and/or powershell, it'd be nice to have an option to skip out on SOLID where it makes sense. If I don't need DI then why must I go through the process of configuring builders and what-not? I have code that does simple things like converting XML to a Cisco switch config. It's mostly repetitive, and a PITA to script, but using c# and .net framework the code is fairly trivial. And I haven't changed it in 10 years. Forcing me to make it maintainable, portable, git friendly, for multiple developers, etc. Would make it pointless to create this utility that helped me generate hundreds of configurations for cloud servers and switches in minutes, compared to the weeks it took to do manually. It speaks to my belief that there are developers, and there are coders. Developers have a mandate to do everything right so others can come in behind them and embrace and extend the code. Coders have a simple problem that needs a simple solution. Doing it "right" is counter productive. It's the very notion of "don't let great be the enemy of good enough" I appreciate your response Tim. This isn't the first time we've had this convo in the Comments, I'm just wishing that MS might skim them and see they're ignoring a valid set of needs faced in the community to attempt to compete with Java, rust, etc.

I'm not sure what Microsoft is going to take away from that suggestion. It sounds like you are arguing with yourself. On one hand, you want things baked into the framework rather than using NuGet packages but on the other, you don't want to be forced to use SOLID, etc. so you want flexibility. These NuGet packages ARE a part of the framework. They are just optional pieces. Think of it like installing Visual Studio. Instead of it just installing, it allows you to choose which packages you want. Yes, that is more complex up front, but it allows you to install just what you need instead of tools that you don't need. You could have a 12GB installation instead of a 30GB installation. The same is true for .NET Core. There are NuGet packages that are optional parts of the framework. You just need to choose which ones you want. As for being forced to do DI, that's not what we were doing. The builder, in this case, was just loading the configuration files we requested (appsettings and secrets.json). That's it. This also has nothing to do with cross-platform. This is just about being a modular framework that doesn't force every project to have an appsettings.json in a certain place (unlike .NET Framework, which required an app.config/web.config in the specific place and was not flexible). If you don't want to use the configuration system, you also don't have to. You could create a CSV file that goes with your app that has key/value pairs and you could very easily load it instead of loading settings. That would work and it would work just fine. You could also hard-code the values in your app if that is all you needed. Put them at the top in constants and call it good. This system allows for more flexibility for you to choose how you want to do it, from ultra-simple and not multi-user/git friendly all the way through enterprise-level secure and optimized. You as the developer get to choose what you want to do.

Yep, I get that.

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!

I haven't used it in years since I don't do many .NET Framework projects anymore. Is there a reason to use it in .NET Core (which includes .NET 8)? Since the transformations are built-in, I haven't found a need. I was wondering if you had one I missed.

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

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/

You are welcome.

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

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.

That's part of being a developer - figuring out how to agree upon standards.

You are welcome.

You are welcome.

You are welcome.

There is a little plus/minus icon to the left, just to the right of the line numbers. Click that to expand/contract the section that it controls.

You have to make sure that the container has the correct access to your SQL Server in order for it to run migrations.

Nope, Dapper is absolutely a tool for everyone. It is incredibly performant and has been proven in high-throughput situations. In fact, larger apps will more often benefit from Dapper over EF because of the performance gains.

You are welcome.

Glad it was helpful!

You are welcome.

I don't love transactions in C# because it includes a network hop inside of the transaction. That can be messy and can lead to open transactions if you aren't careful. I prefer to do transactions on the SQL side. However, sometimes that doesn't work. For instance, in the TimCo Retail Manager course here on UA-cam, I use a C# transaction out of necessity. When using a transaction, you should make sure it is necessary. For instance, if you are only calling one stored procedure then a transaction is not necessary in C#. Instead, if you are doing multiple tasks inside of the stored procedure, you can put the transaction inside of the stored procedure. It would only be if you cannot change the stored procedure that you even consider using a C# transaction. Even then, I would recommend a new stored procedure instead. Taking the transaction code away in C# won't really show you anything. That code only executes if the transaction fails, so unless you are testing that part of it, everything should work. Be careful to fully understand the why before taking out working code.

Thanks.

Oh one slight difference between your setup and mine (I believe so at least) is that I am using the SDK style project setup. The reason I believe you don't is because you posted this video 4 years ago and you did not get the notification I did saying that 'pack' was not possible on SDK style projects.

There are options, but the easiest one in my opinion is to use a text field. You could use an integer and calculate seconds from 1970 among other options, but those options aren't human-readable when scanning database columns. I prefer just using text and converting it back to DateTime.

@@IAmTimCorey So If We Have A DateTimePicker named as DTP this means we can define string theDate = DTP.Value.ToString("yyyy-MM-dd") OR Something Like This and Then We Should Store THis String onto the DB

There is always going to be a careful balance to maintain, which is what I talked about in this video.