Oh man, i can't see it today, but i'm super hyped to see it tomorrow. It feels like waiting for a GoT episode. I'm i the only one getting "fangirl feelings" for a programming video? Jisus lol
FYI, Mine worked the first time after installing System.Configuration.ConfigureationManager to TRMDesktopUI.Library. So, I skipped installing it on TRMDesktopUI. Thank you Tim! [Update] After restarting VS 2019 and rebuilding the solution again, I then had the same problem as Tim. Also, try adding a Role. If it's not adding a Role, then something's wrong. Mine didn't even give me an error. It just didn't add the Role. After I did the quick fix Tim did, Role was added and removed like it should.
There was actually another solution to the problem with the configuration files. That could have been an interface in the .net standard library one and in the wpf can be implemented using the old way from wpf. If that was done, then the standard would not even care how its being done. Plus, more flexibility so if you wanted to get the data a different way, that would be easy. I enjoyed the video you had about interfaces and can see why its best as much as possible to code against an interface and not an implementation.
You mean I should create a class in WPF that looks up the config and then pass that class down to the class library as a dependency via interface and DI? That would work. When we get to .NET Core 3.0 it won't be an issue though.
@@IAmTimCorey One advantage of doing with DI is you are not even locked to using config file. If you ever at some point wanted to store in azure, then it would work. In that case, the system would not even care how it got the information.
It is indeed scary to erase the content in the csproj file‼ But I followed the instructions and typed in the new content and reloaded the project. The result was even more scary‼‼ I did the project so far with VS-2022 (.NetFramework 4.7.2) and everything worked just fine! But after reloading the project the project-property page now shows under section "TargetFramework" the (only one) listentry "unsupported" - and for me the "TimCo Retail Manager Course" came to an abrupt hold since nothing works anymore!!!! (Of course I did a reset to the old version and at least this works again.) (BTW... for new VS-Projects the whole array of TargetFrameworks from Net Core 1.0 all the way up to Net 6.0 is available) What to do now❓❓❓
Tank a lot for your .netStandard 2.0 upgrade process and particularly the debugging session. information for others. My WPF project did have more packages than you have in your project. Don’t ask me why. So I've decided to perform a big clean up and put the System.Configuration.ConfigurationManager packgages at the end. Today I’m happy customer 😉
suggest having the NuGet setting to promote the "preview" flavours [i.e. bleeding-edge] is unnecessarily dangerous btw as an old lion-tamer, I recommend newbie lion-tamers don't offer their head into lion's mouth just because you can [better to enjoy long-life and with both ears]
I understand but sometimes you need to do cutting edge during an upgrade. We will see this most clearly on Friday with WPF. This is cutting-edge training, which will last for a long time but right now it is going to be right on the edge. It won't be mainstream until probably mid-2020.
@@IAmTimCorey but MS have GA'ed DotNET v3 and that includes the many NuGet packages (i.e. "official" not bleeding edge). My advice is to [at least] start with non-preview packages and get them working, and then maybe go to preview and overnight build stuff if they really want latest adrenaline rush.
agree that deleting packages and app.config files seems scary. Instead of c+p into Notepad (ugh!) you can change the properties setting to ignore for compile/run time then you've got them to view (without having to use version control) but they dont cause grief/conflict. when done later, delete altogether
Hello Tim, and thank you for the great tutorials. I would like to share my experience regarding to the Error (System.IO.FileNotFoundException), I installed "System.Configuration.ConfigurationManager" package to the WPF project. But after I launch the project for the first time, I went back and I Uninstalled it and I didn't get the error again.
When a .NET framework app uses a .NET standard library, it doesn't know how to copy it's dependencies into its build folder. Here's how you tell it how: PackageReference Add below line in the first "PropertyGroup" tag of the .net framework console application's ".csproj" file
I didnot encounter any problem. After installing System.Configuration.ConfigurationManager on the class library, solution worked properly as expected. I didnot change anything on the desktopUI project. Differences from yours: In the intellisense where ConfigurationManager is not recognized on the Class Library Project, I had recommendations different from yours. In your case you had suggestions installing NLog and Microsoft.IdentityModel.Protocols, whereas I had suggestions Microsoft.IdentityModel.Protocols and System.Configuration.ConfigurationManager. I just took it suggestion for ConfigurationManager and done. The other difference, I didnot need to delete app.config file that you deleted, because it did not exist after changing csproj file.
On the first part, I think that is an improvement in the recommendations system. For the second part, that does not sound right. You should still have an app.config file.
Just in case someone else has the same issue the final launch of the app didn't work for me until after I did Rebuild Solution. At first I got "Internal Server Error" for my error message. I decided to Rebuild Solution and try again. Even then I got some weird behavior where the API HomePage didn't launch, but I was able to log in to my application. I then launched the application again and it started working like normal with the API and WPF.
I think I did exactly you did and also got the same errors until 20:05, when I did not get the exception, it runs fine. Should I cry or smile? I noticed that my app.config has an extra line at the end: Actually does make any difference if it's commented out or not.
Ok, I've got the same Configurationmanager nuget package version (v5.0.0) installed in both projects. However, I don't know what brought it into TRMDesktopUI, because it is not listed among its nuget packages.
Error: Could not load file or assembly 'System.Net.Http.Formatting, Version=5.2.9.0, Culture=neutral, PublicKeyToken=31 bf3856ad364 e35' or one of its dependencies. The system cannot find the file specified. Solution: In the TRMDesktopUI.Library, the 'Microsoft.AspNet.WebApi.Client' package version should be 5.2.7 NOT HIGHER!
IAmTimCorey, why when you see exception message you don't check System.Configuration version in UIDesktop project's References? It can help to spent less time to debugging this exact problem. Is it just to show workaround methods?
@@IAmTimCorey 16:17 - you install system.configuration.manager version 4.7.0, 20:06 - you get exception with message "Could not load file or assembly System.Configuration.ConfigurationManager, version=4.0.3.0...". So isn't it mark of different version of libraries? And you can check this by open Solution Explorer and checks properties of System.Configuration (System.Configuration.ConfigurationManager) Reference at DesktopUI Reference subtree at version value. I mean isn't it rational to checks first difference in versions if you know that your library and desktop application use different versions of ConfigurationManager?
@@IAmTimCorey actually i was wrong about References section, there are no any traces of this problem. But in exception you can see version of library program trying to search, so if you know that you use in library different version isn't it trace that you have compatibility issue?
Tim - Do you have an introductory course on .Net Core? I'm very new to .Net framework and would like to familiarise myself first with .Net core and then proceed with advanced topics
@@IAmTimCorey Thanks. I checked the link you provided but not sure if you cover these topics - DI, Service Configuration, Middleware, MVC, OAuth, Publishing etc.?
It touches on DI, Service Configuratino, MVC, and OAuth but this is an introductory course. It doesn't go into depth in any of these topics. That will come in a later course.
I have a suggestion. Could you use .net standard 2.1? Because the latest standard is 2.1 even though it will not work on desktop. However, 2.1 does work for xamarin forms though.
Not working with desktop apps is the problem there. This app has desktop apps and part of the reason to go to .NET Standard is to allow for backward compatibility. I will be doing a video on .NET Standard 2.1 at some point, though.
@@IAmTimCorey How would you use a lot of the new c# 8 features that unfortunately only work on 2.1 like auto implemented interfaces or async streams, or ranges
@@onyebuchiboss I actually created a game package that uses interfaces quite a bit. Even did for messageboxes so it would mean that the cross platform can even do message boxes or even other ui and xamarin can implement it differently than wpf. The interface would be in standard but can be implemented in xamarin or wpf.
surprised you never showed the Output window that shows the progressive loading of .dll files ditto you never taught the logging aspects ; likely upping to Verbose would have given useful info rather than relying on blundering about (sorry "pragmatic") approach!
lol, yeah, I didn't go in depth on these issues since this is more focused on the upgrade itself rather than explaining how it now works in .NET Standard. We will cover those things in the future and review what we should adjust the settings to be.
