In C# 10, we have the ability to set global using in our application. See how in this 10-Minute Training video. Full Courses: iamtimcorey.com Source Code: leadmagnets.ap... Mailing List: signup.iamtimc...
Its still RC (release candidate). I am waiting until first real release. But you should focus on dotNet 6, because its gonna be LTS (long term support). DotNet 5 is not
Thanks for showing this. I probably will not use it. For me it is OK to see explicitly all dependencies between namespaces you create in an application. Shorter code is not always better code.
@@IAmTimCorey Yes. I like your videos and the improvements of .NET 6 and C# 10. I will definitely use them as soon as it is official released, even I use only some of the new features.
Hello, another great material, I'm waiting for more. I understand that this new "global using" is optional? It seems to me that the standard approach helps to avoid namespace errors. If this approach is not required, I will stick to the old one.
This has nothing to do with scope. Remember that a using is just a shortcut. You aren't importing anything or bringing in a dependency. You are just shortening the name. We do that already at the top of files. Now we can do that at the "top" of the application instead, for things that we add to the top of every file normally. The compiled code won't change at all.
@@IAmTimCorey When you do it at the top of a file, it is an explicit statement that those libraries are used in that file. When you do it globally, those libraries will be in the scope of files that don't need them. This is going to create an incentive to put more and more things in the global using out of convenience rather than necessity.
No, this is a misunderstanding of what usings are. They do not say that the file has a dependency on a certain library. If you put "using System;" at the top of your file, that does not declare a dependency on System. It just means you don't have to say "System.Console..." It is a text shortcut. Your *entire application* depends on System, regardless of if you have a using at the top of any given page. If you want to see your project dependencies, go to your csproj file. That's where those dependencies are stored. As for the idea that global usings will be created "out of convenience rather than necessity", yes, that's the point. This is a convenience issue. Programming isn't supposed to be hard for the sake of being hard. Convenience is the entire reason we have C# instead of Assembly.
@@IAmTimCorey I didn't say the using statements created dependencies. I said that they are a declaration that that particular file uses those libraries. It's a form of documentation. A global using breaks that link. You now have to assume that every file uses every library referenced in a global using whether they do or they don't. You could make the convenience argument for anything to any degree. Why not make more variables global? That'd surely make some programming tasks more convenient. Defensive programing isn't usually the most convenient thing to do, but it is often the right thing to do. Btw quantity matters. It is fine for me to take my money out of a bank, but if everyone does it, the bank crashes. Likewise a limited set of globally known _(pun intended)_ set of functions available to all files is fine. Anyone programming in C# knows what's in System. It's more a part of the language than library calls. It's when custom libraries are added on top of that where things can get dicey for large projects.
Couple of things - first, the reason you shouldn't use the usings as a means of documentation of reliance on external libraries is because you don't have to use a using to reference an external library. Second, the list of usings at the top does not indicate that the libraries are all in use. You can have unused usings. As to the idea that you now have to assume the file makes use of those usings, why is that bad? You aren't putting everything in the global usings. You are putting things in where they are globally needed (or practically so). Things like the using for your models namespace. As to the argument that you could make variables global too, you have that option. Just like with global usings, you can use it or not. However, in the case of global usings, it adds nothing to the overhead of the application. It will compile the same with or without global usings. Global variables take up more memory and cause other issues. Bottom line is that you now have an option you did not have before. You can use it or not as you see fit. It will not cause any performance issues and it will not break your code either way.
I hope they don't break the whole language with these rapid changes. With the aid of IDEs these days we shouldn't have to be considered with typing multiple extra characters rather than be sure that the code is safe in the long run, which is what the C# was about
These features (global usings, implicit usings, DateOnly, TimeOnly, file-scoped namespaces, deconstructor updates, LINQ improvements, extended property patterns, and more) are all opt-in for old projects and opt-out for new projects so there won't be project disruption. These are additions and improvements, not replacements that would cause a problem. That's why they named the new date type DateOnly, so that it didn't conflict with existing code and break something. The .NET team is very aware of how their work can affect others and they do everything possible to not create breaking changes.
@@willinton06 I didn't mean when you compile things, they would break or something. What I meant was the software engineering aspect of these changes, maybe pushing developers to write more unreliable codes by not using proper namespaces. They probably think that through a lot but I just worry maybe they preferred simplicity over reliability, which I don't think is a smart move
@@IAmTimCorey I wasn't clear enough in my comment, I'm fully aware of backward compatibility of the framework. What I meant was the changes that make or push programmers to write unreliable codes are not encouraged. Like the ability to add static methods to interfaces added in c# 8 which I'm not really a big fan of. But of course developers who follow the best practices principles shouldn't be worry beacuse adding extra features to a language doesn't harm in that sense.
Thanks for the lesson. Good feature to use for simple file headers but explicit using statements at the top of my files shows me a summary of what I have been doing in my files.
This is a great feature, IMO, because it defaults to encapsulation rather than everything being publicly accessible from anywhere. So if you want a class to be accessible from another project, change the keyword. It becomes an interface for the project, where by default before, everything was an interface for the project.
@@josda1000 Interesting but the old default was no modifier at all and everyone just declared it public. Including Tim Corey (Looking at all those videos :D ) so what's to say people won't just replace it with public like they used to or change the template altogether?
@@pl4gueis that's exactly the problem... the default is public (when there is no modifier). I mean, it's not a problem, it's a choice, but good design suggests limiting encapsulation as much as possible so that 1) you convey meaning and 2) you don't accidentally open things up they way you didn't intend to during design. So sure, make everything public again by putting the public keyword there or deleting the internal keyword if you want, but i suggest thinking about design first before doing so, because that's the purpose of the change.
@@josda1000 Thanks for clarifying. Didn't know that without modifier its public already. Encapsulation is still something on my todo list to read up on. Unfortunately design is usually the last things my senior devs worry about so not much to learn from them.
Sorry, but they are called "using directive". There is also a "using statement" and a "using declaration". The using statement is the one with the Dispose() on the closing curly bracket. The using declaration is the one where the Dispose() is done implicitly at the end of the block. I really hate to be nit-picky, but following this naming convention helps to reduce confusion when talking about those things.
Great Video When I do WPF/ MVVM development, I put all my global using's on my main ViewModel file. That way I don't have to create a extra file. I love this feature, it saves a lot of time, I don't have do a bunch of using statements to import my libary to the project.
Thanks for the lesson. I absorbed more from this than the messy tech docs covering this topic. I'll definitely use this when we move to 6. It might be nice to constrain your global usings to a namespace to allow better control.
I would probably define the global using in program.cs or startup.cs and as a standard I would be global using all the folders in the program like program.models, program.services, program.interfaces, program.controls.
That would work. I just like separating it into its own file so that we aren't having a file doing two different things, but that's just a personal preference.
Thanks! Another super useful feature in C# 10 that I will use all the time. A minor point: Wouldn't it be marginally better to call the file GlobalUsings.cs rather than Usings.cs?
That could be true, but do you really anticipate that you will be doing that on a large scale and will be confused? Do you often find yourself referring back to the usings at the top to identify where something came from? Personally, I almost never even look at them except to add the ones I need.
Hi Tim, yes you are right, I won't be doing it that often and, since I am already aware of this (thanks to you ;)), won't be confused either. However sometimes I really do need to check the usings. For example on some big and relatively old enterprise codebases there are many domain libraries with similar class names, which is already quite a mess. Also I always check the usings while doing a codereview to see if there are some new unnecessary dependencies (along with csproj files or package configs). I am personally not going to use this feature. Rider IDE already has kind of solution for it: collapsed usings by default (not sure I like it though) P.S. since this is the second my comment on this channel (the first one is above) I'd like to thank you for being my source of news about .Net!
Adding this to code reminds me of the old days in COBOL, with “Library Statements.” “‘Using’ that Library, gave you access to everything in it.” Yep! Thanks, Tim! I can’t wait to use it in Class! (I love these short insights, BTW!)
Yep, just remember that the using statement in C# is not bringing in the dependency, it is just a typing shortcut. The dependency is already a part of the project and loaded.
I’m somehow getting auto generated global usings, but visual studio can’t build my app now, cus it throws a CS0116 error… the auto generated code IE: global using global::System. Any clues on what’s going on?
While I see its utility, this is why I'm not a fan of multiple header files from C & C++ as the abstraction is hard to follow when having to dive into someone else's code in a hurry to fix a problem. Used sparingly I can see its benefits, but with caution!
Not a huge fan of this. The value that it does add in terms of convenience, seems out weighted by the potential for crossing wires in the brain. Namespaces are logical and easily understood. Is there additional benefit here that I’m missing?
Simplicity. Right now, the class templates add about 4 or 5 using statements by default because we almost always need them. When I create a Models namespace, I reference it everywhere because I use models throughout my application. Why should the top ten lines of each class be identical? Why should we spend a few minutes per file adding each of the using statements? By saying "these usings are needed practically everywhere", we reduce a LOT of repetition. We also speed up development a bit. As for the "crossing wires in the brain", I'm not sure what you are referring to. If you mean that you will lose track of which namespace something is in, mousing over it will still show you. If you mean you will forget what is a global, the system will tell you if you add an unnecessary using. If you mean you will have globals all over and get confused as to where they are, that's on you to organize better than that.
I'm old enough to remember when people suggesting that anything be 'global' was considered bad programming technique and unsafe and also lazy. C++ folks would need weeks of therapy at just the notion of it.
can get rid of all the using statements for EntityFrameworkCore (and much more) from most of the files. Is there any easy way to make Visual Studio to not put those default using statements in .cs file when you add a new one? First thing I always do is getting rid of them and then add any as I implement. Don't know how many days I've lost just doing that :D
The feature should really be "global useless." It's like putting a laser sensor on a toilet because people are too lazy to use the toilet lever! How much effort and code is used by typing a using statement? How does it improve the quality of our code or increase the C#'s capabilities? It only invites bad programming practices especially by undisciplined and lazy programmers. Microsoft is playing follow the leader again by appropriating bad ideas from other languages like Swift and Python. This feature along with Records and removing the entry point preamble is another pathetic attempt at winning over shitty programmers from the open source world where everything is built upon a teetering tower of babel. What will they add or remove next? Indent based execution blocks? Truthiness and falsiness? Why not steal productive features like algebraic types from languages like Swift and F#. The idea of combining types to define other types is pure Nirvana and takes type safety to a whole new level.
Nah, this is a bad take. If this were the case, we shouldn’t use usings at all (because they encourage developers to be lazy and not type the full namespace). Global just took usings one step higher. That reduced repetitive code. They already have it in Blazor and that’s been a great success. As for records, watch my video on records. There is a good reason for them. Besides, they are just classes with syntactic sugar so using them is no different than writing that code yourself. If you don’t want that functionality, don’t use it.
I've just started with c#because I just got hired on my first dev job, until now, I've only used JavaScript, css and html with vs code, I feel like I'm starting all over again, thanks for this video, do you have any updated full course of .net6 and c#10?
I have the C# Mastercourse ( www.iamtimcorey.com/p/c-mastercourse ) that has been updated for .NET 6 and Visual Studio 2022. However, there will be things covered in .NET Framework as well. The reason why is because you really still need to know it as well. The good news is that everything you practice in .NET Framework will also fully work in .NET 6+. If you purchase the course, it also has three bonus courses. One is a dive into the .NET Versions and what the differences are and how it has changed over the years, what is important to know, and what is going away. Another contains all of the course content that has been upgraded as new versions came out, so you can still have the older content if you are working with older systems. The last is a coaching-style course called the Year of Coding that walks you through the training and gives you weekly advice, challenges, and more.
I believe I'll use it. I find it distracting to add the using clauses all the time... my background id RPG/ILE RPG programming. The usings, while make sense, are a distraction. It would be nice to put them in one place and be done with it...
But what about global using System.Collections.Generic in a large project for instance, where this namespace is not used as often as System let say and many classes does not require using Collections. How does this affect the performance of the application?
Couple things here. First, the generic collections will be one of the more useful using directives in your application. In a big application, they are used all over. Second, and more importantly, adding a using directive (globally or per file) does not make any difference to the performance of an application. A using directive does not add the library into memory. It does not change what code is available to your application. The only thing it does is allow you to shorten calls. So System.Console.WriteLine becomes Console.WriteLine. So you could have 1,000 global usings and it would not have any performance implications at all. The only implications are for namespace collisions, where two methods are named the same thing in two classes of the same name. In that case, you will have an ambiguous name collision, which would be fixable by either taking away one using or by using the fully qualified name instead of the shorter name.
when the application is built, using directives are connected to their classes already. Since these are marked as global, they are also considered when looking at which using directives are needed for a given class.
This seems WAY overdue. As much as C# has focused on code cleanup and consolidation over the years, seems like this would have been part of a much earlier version. I definitely think it's useful for System namespaces/classes and any libraries/classes you may use on a project-wide basis. Nice addition!
I can only see very limited use for global using statements. It seems like namespace collision nightmare in growing projects. If it was in a smaller project with a very narrow context then maybe. I just couldnt justify the inevitable namespace debugging session for the convenience/code cleanliness/'time saving'.
Developers. Not ever developer, but enough of them. We've had the same boilerplate code for years, so we've gotten used to it, but why do we have so much ceremony around our code? We implement DRY in our code, yet we hadn't in the "standard" code. This is that change. Instead of repeating ourselves over and over, we can now do it once. Blazor has had this from the start with the Imports file. Now the rest of C# gets it.
If you add a *global using* that is one of the using statements that are put in automatically by Visual Studio, i.e. if you add *global using System.Text* , are they still added by default when you create a new class?
I see its relevant with these 10 min or less vids, with C#10 and dotNet 6. But I really prefer indeepth look. At real world applications. Because that is what we are trying to make. Real world applications. But thanks Tim always a pleasure to watch 👌
Okay, this one I am 100% onboard with -- and about bloody time too! This will make things sooo much easier to manager! instead of having to add using statements all over the board. This I will absolutely be using. It speaks right into my Autistic Universe. lol
@@IAmTimCoreyWhat happens if you send someone a file or gist? How do they know if you're "using" System.IO.Console or "Tim.IO.Console"? You now created a dependency where there wasn't one.
@Bob - That argument doesn't really hold up because if that was really a big concern, you shouldn't have a using at the top of the file either because "what if you wanted to send a method to someone?" Remember that using's aren't bringing in libraries. They aren't importing anything. They are just shortcuts. If you sent a file and didn't include the dependencies, that's on you. If the file did depend on "Tim.IO.Console" then your gist wouldn't work even if you did have a using at the top.
@@IAmTimCorey valid. But, finding the dependency will be more difficult than if the using is at the top of the file. Unless it becomes a standard to include "using files" just like you would include dependencies.
First, you don't need to use it. Second, I'm not sure how it could have that big of a negative impact on your code. These aren't importing libraries. They are just shortcutting how we call them.
I know you're not soliciting my opinion but thought I'd chime in if that's ok... It seems to me that if you keep the usings separate, you'd have a central place to go and won't clutter the project file. If you're working with others, you might confuse others if you keep everything together, especially if you have a "global using System" directive, something so generic that people will be like "wait, what's going on here?" Just food for thought.
I like them in a separate file that is clear and obvious. Reusing files for multiple purposes leads to a structure where things are hidden instead of visible.
How would you go about creating transitive global usings? I have couple of solutions right now, but none of them is ideal: 1. Declare all global usings in Usings.cs, and manually include it as a link in all dependent projects. If said project also has Usings.cs, `DependentUpon="Usings.cs"` can be added so that VS automatically nest them. Downsides: - Usings.cs need to be manually included - Files are visible in solution explorer (I'd prefer this kind of configuration be located in csproj) 2. Declare all global usings in Directory.Build.props so they are autoincluded (``). Downsides: - It will include it virtually in every project which is not the intent. Each project would need to have it's own Directory.Build.props to only include usings from project it depends on, or something.
@@IAmTimCorey I know. But imagine you have some Domain project (or UnitTests.Common, or some other common project) that's included in a bunch of others. Every dependent project would need to declare usings from that common project as global, since they are used everywhere (or in the case of UnitTests, every such project would need to declare Moq, Xunit, FluentAssertions, Bogus and UnitTests.Common as global). This clearly violates DRY principle. Any moderate to big application is comprised of multiple projects, and most usings in those projects are the same, so having an ability to create a transitive global usings would be really useful.
No, it doesn't violate DRY. DRY isn't about eliminating code that looks the same. DRY is about not repeating the same logic in more than one place. That way, if there is a bug in the logic, you can change it once instead of multiple times. We repeat code all the time. Namespace declarations are repeated constantly. The "using System;" used to be at the top of every single class in your application. Now we can put the using statements in our app once if they are used everywhere (global usings), but having them work cross-project would be unwise. It would create a dependency across projects, which is not something you want to do, nor can you do so both ways (circular dependency). Plus, each project is going to have a different reason for existence. A different purpose. That means that each project will have different usings.
@@IAmTimCorey 1. NuGet and project dependencies are already transitive (we don't need to add a NuGet if project we depend on is already references it). I'm not saying that all global namespaces should be transitive, only that we should have an option to state that any specific one should be (like ""). 2. As I said in the previous comment. Many projects will have similar using groups that are included in most classes (like Moq, Xunit, FluentAssertions, Bogus for all UnitTest projects), so those global usings would need to be repeated multiple times. And if some common dependency is added / removed, global using for it will need to be updated in multiple places. That's what I meant about violating DRY, that the same work needs to be done in multiple places. Regarding namespaces, yes they are duplicated, but developer doesn't do the work to do this - VS does. And when files are moved there's even a "Synchronize namespaces" command in VS now, to not have to manually update all of them.
I'm looking forward to the new global usings. It helps keep things more organized because one file will have all the usings so i know all the dependencies in my projects.
@Bob - Stop with the personal attacks. I get that you don't like this feature but that doesn't give you the right to attack others or put them down. And to address your statement, this feature has nothing to do with global variables. This is about a shortcut being global instead of per-file. When the code compiles, the result is no different than what you are doing now.
I've heard this argument before, but I don't really understand it. The usings list isn't a comprehensive list of what is used in a class. It also isn't a list of dependencies. So, I don't see how it is used for useful information. The only thing it really tells you is what items you created shortcuts for. If we are constantly creating the same shortcuts, why aren't we making our lives easier? We do that in other areas. We create methods that stop us from repeating our code. Those method shortcut calls, but we don't see those shortcuts being used because we call the methods. I don't see it adding value to keep the usings. I do see it reducing effort to centralize the common ones.
Actually, you can. Visual Studio has a setting where, if you paste code in that needs a using statement, Visual Studio will add in that using statement.
I haven't been following the evolution of C# recently, but noticed a few other nice syntactic changes in your video. The omission of an explicit Program class and main function makes a lot of sense to me. Thanks for the explanation!
hi tim this might be out of scope. Can I ask you something? If there are any way to loop through directory, CUZ every time I try to do that it's said 'Path access denied'. Is there any way to solves this ? I had look Stack Overflow but don't really get much out of it.
@DJ is correct. The issue is probably permissions (you have admin rights but the app does not), but they can help you more. Just be fully descriptive and search for similar problems first (they are there).
This belongs to that process that, with minimal api, would take a nodejs developer be familiar with c#10 as well as let developers to have file without the same "using" redundant, without unuseless lines of code.
