After Node - React JS, it is difficult to switch to WPF, but your course gives the right information to quickly link to WPF concepts. Thank you very much.
Ahh I'm the opposite (WPF -> Node + React). I think as you get deeper you'll start to see some slight similarities between WPF and React. Very slight lol, but the big picture is still similar. I wish I had been more experienced with React before getting into WPF. A lot of concepts I've brought into this channel have been inspired by front-end web frameworks. Anyways, that's enough ranting. Glad these tutorials have been helpful!
Thank you so much for this. I really want to have a beginner-to-advance books that deals with this technology. All I can find on the internet are fragmented tutorials.
Thanks for your videos man, for taking your time and publish this valuable information, im becoming a better WPF developer because of the knowledge you share.
Is it possible to wrap the entire App.cs in a host? I have this code in Main: HostApplicationBuilder builder = Host.CreateApplicationBuilder(args); builder.Services.AddSingleton(); IHost host = builder.Build(); host.Run(); The program seems to be running but no window is showing. How do I call App.Run since host.Run is blocking the thread?
Just a little heads up, unless the issue has been fixed in .NET 6, registering disposable objects as transient will cause memory leaks as the .NET host doesn't call Dispose() once they go out of scope, so the instances just sit in memory. A fantastic video nonetheless 👍
@@codingdave Hmmm not sure about net framework, but the last .NET 5 app I was working on recently was holding on to the created instances rather than calling Dispose and removing any references. Apparently it's an issue that's been around for quite some time
I suppose that, while such approach might actually be kinda overkill for smaller projects, the main benefit of this is in the bigger ones, where a long-term maintainability is required and where often several people work on project, right? That way, a program could be highly 'modular' so that different people could work on different parts of it independently and it would be easier to add new functionality. I mean, obviously this is not such a project, but we're pretty much doing this here for educational purposes so to speak, right?
Hey Human Rayla! I've actually never really tried this in a production app. I would assume the process would still get killed, and the host would get cleaned up automatically. I can't confirm that though. I will say that when I'm debugging in VS and I don't dispose the host, sometimes my debugger keeps running for a while despite closing the window. This is kind of annoying, so I think it's probably a good idea to just dispose the host.
The tutorial is too fast and does not explain why things work. For example, around 13:44 he registers a Json file as the application settings JSON and calls "hostContext.Configuration.GetConnectionString("Default")". He doesn't explain how or why hostContext knows about the JSON file he created, nor does he explain how this function knows to fetch the connection string property from the object he created. All he did was create a JSON file with the value "ConnectionStrings":{"Default":"Data Source=reservoom.db"}. And somehow magically it works and we don't spend a second figuring out why. Sure most likely the name of the JSON is a name this function excepts and it's the same as the name of the ConnectionString object. But how are we supposed to know this from this tutorial? What are the names this thing expects? Where should the JSON file be saved? If you put it in a sub dir, will it still know to find it? This is still very educational insofar as showing that this functionality is possible. But sadly to actually understand how this works, one needs to look for a different tutorial.
Whoa hey there TheWolverine1984. First off, glad these tutorials have been helpful! Good questions and criticism here too. The default host (which we created via Host.CreateDefaultBuilder) will automatically load settings from an appsettings.json and appsettings.[environment].json file that is adjacent to the executable. I try to go in-depth when necessary while not dragging out the tutorial too much, but I agree that would've been good to mention. Thanks for bringing that up, and let me know if you have any other questions.
@@SingletonSean Thank you for the reply, i didn't mean to be overly critical. Sometimes things that are obvious to knowledgeable people are not obvious at all to someone who's just beginning.
After Node - React JS, it is difficult to switch to WPF, but your course gives the right information to quickly link to WPF concepts. Thank you very much.
Ahh I'm the opposite (WPF -> Node + React). I think as you get deeper you'll start to see some slight similarities between WPF and React. Very slight lol, but the big picture is still similar. I wish I had been more experienced with React before getting into WPF. A lot of concepts I've brought into this channel have been inspired by front-end web frameworks. Anyways, that's enough ranting. Glad these tutorials have been helpful!
Thank you so much for this. I really want to have a beginner-to-advance books that deals with this technology. All I can find on the internet are fragmented tutorials.
I love when you say "and now"!
Hahah thanks Axel. I do have quite a few catch-phrases that people accuse me of always saying, I'll add that one to the list lol
Thanks for your videos man, for taking your time and publish this valuable information, im becoming a better WPF developer because of the knowledge you share.
I love the way you explain ❤️❤️..
Excellent - not least because I had not disposed of the host in an existing app.
Is it possible to wrap the entire App.cs in a host? I have this code in Main:
HostApplicationBuilder builder = Host.CreateApplicationBuilder(args);
builder.Services.AddSingleton();
IHost host = builder.Build();
host.Run();
The program seems to be running but no window is showing. How do I call App.Run since host.Run is blocking the thread?
Just a little heads up, unless the issue has been fixed in .NET 6, registering disposable objects as transient will cause memory leaks as the .NET host doesn't call Dispose() once they go out of scope, so the instances just sit in memory. A fantastic video nonetheless 👍
Really? In net 472 i have to remove my dispose calls to not dispose twice.
@@codingdave Hmmm not sure about net framework, but the last .NET 5 app I was working on recently was holding on to the created instances rather than calling Dispose and removing any references. Apparently it's an issue that's been around for quite some time
Great point coding gerbil! I actually wasn't aware of that, I'll keep an eye out for that
I suppose that, while such approach might actually be kinda overkill for smaller projects, the main benefit of this is in the bigger ones, where a long-term maintainability is required and where often several people work on project, right? That way, a program could be highly 'modular' so that different people could work on different parts of it independently and it would be easier to add new functionality. I mean, obviously this is not such a project, but we're pretty much doing this here for educational purposes so to speak, right?
What would happen if you didn't dispose the host? I kinda figured closing the app would close everything
Hey Human Rayla! I've actually never really tried this in a production app. I would assume the process would still get killed, and the host would get cleaned up automatically. I can't confirm that though.
I will say that when I'm debugging in VS and I don't dispose the host, sometimes my debugger keeps running for a while despite closing the window. This is kind of annoying, so I think it's probably a good idea to just dispose the host.
Thank you
Will there be any winui 3.0 stuff in the future?
Not in this tutorial, but in the future of my channel most likely :)
@@SingletonSean Excited to see WinUI3 in the future!
The tutorial is too fast and does not explain why things work.
For example, around 13:44 he registers a Json file as the application settings JSON and calls "hostContext.Configuration.GetConnectionString("Default")". He doesn't explain how or why hostContext knows about the JSON file he created, nor does he explain how this function knows to fetch the connection string property from the object he created.
All he did was create a JSON file with the value "ConnectionStrings":{"Default":"Data Source=reservoom.db"}. And somehow magically it works and we don't spend a second figuring out why.
Sure most likely the name of the JSON is a name this function excepts and it's the same as the name of the ConnectionString object. But how are we supposed to know this from this tutorial?
What are the names this thing expects? Where should the JSON file be saved? If you put it in a sub dir, will it still know to find it?
This is still very educational insofar as showing that this functionality is possible. But sadly to actually understand how this works, one needs to look for a different tutorial.
Whoa hey there TheWolverine1984. First off, glad these tutorials have been helpful! Good questions and criticism here too. The default host (which we created via Host.CreateDefaultBuilder) will automatically load settings from an appsettings.json and appsettings.[environment].json file that is adjacent to the executable. I try to go in-depth when necessary while not dragging out the tutorial too much, but I agree that would've been good to mention. Thanks for bringing that up, and let me know if you have any other questions.
@@SingletonSean Thank you for the reply, i didn't mean to be overly critical. Sometimes things that are obvious to knowledgeable people are not obvious at all to someone who's just beginning.
I dont get the point of it, what was wrong with using the code you replaced ?
Hi !!!! Sorry but, I get the same error: has been registered, what it means? services.AddSingleton((s)=>new LoginView(s.GetRequiredService()));