I'm not clear how any of this is better than right-clicking the solution and choosing Manage NuGet Packages for Solution and just letting it update all the packages itself. Does it speed up AZDO build pipelines or something? I guess as Microsoft pushes people away from Visual Studio and towards VSCode and the command line, this will come in handy. Especially on Mac. Maybe I answered my own question.
I guess it can be for cleaner commits. Committing in a centralised place rather than across multiple project files but it's only a very small benefit. The 2nd part of having a global package just seems nice for cleanliness also
@@JamesMontemagno but it's easier to manage nuget packages for solution using the GUI rather than adding manually the references in the props file so I'm not sure if you are saving time. It also means that I cannot use the GUI anymore to install new nugets right?
@@almis6470 Yea, the bigger problem is that if someone doesn’t know this feature is being used and they’re used to looking at versions in the GUI, they are going to get confused real fast. The feature seems half baked because of this and may actually waste more time than it saves. You also have to wonder how committed Microsoft is in that case since they’ve disabled these type of half supported solution level flags and features in the past.
That is what I showed first, you just don't specify a PackageReference per usual in the project. You just are centralizing all the versions. If ALL of your nugets are different in each project... then up to you if you want a more central place.
@@JamesMontemagno not very clear still... do you mean the moment you showed somthing with a star like 8.0.0-* ? or somethings else... if you mean the star, then do we set the Version attribute inside of the projects which use different versions? will system not give us error then? Actually I have all the versions same but I was curious as well and this comment brought my attention to it
@@JamesMontemagno So GlobalPackageReference is mostly useful for packages that will be in all you projects. If I have a solution with 60 projects I would not expect all of the to use FluentValidation. Does this Global reference mean the package is considered for compiling/linking your code, hence it is taken on a ride in building *all* you projects in that solution?
PackageVersion is in essence replacing the Manage Packages for solution and then use the Consolidate option? You also did not show how you would then Update a package to a newer version, can I still go the any project and say Update to latest, and VS will default to updating the Directory.Packages.props instead of adding a version to that project. Or is this a manual editing task at this time?
Is the nuget package manager taking into consideration the GlobalPackageReference when updating or adding a dependency so that it doesn't add the ref in the given project's csprojs ?
So the PackageVersion is maintained per solution? Or could I move it up even more. As you explained we have an applicaiton consisting of multiple solutions all generating different programe and we either use multiple solutions, or solution filters. Would you need to have the Directory.Packages.props file at the solution file level, of when I use diferent subfolder for different solutions I can put it in the repo root folder for instance.
Wildcard package versioning is not supported. A big disadvantage. Once enabled, all package versions are to be defined only in this file. And only version # can only be overridden if necessary. Reference cannot be defined directly at the project level, even if needed in only one project. A cumbersome process. It should be rather a hierarchical definition.
Hey James, great video on! While I'm definitely a fan of managing packages at the solution level, I do have some reservations about the Global Reference feature. While it streamlines things, it seems a bit too broad for my liking. For example, it would be awesome if we could set Global References specific to types of projects, like Tests. I know we can achieve something similar with PackageReference, but the Global Reference feature seems like it might be a step too far in generalizing dependencies. Would love to know your thoughts on this or if there are workarounds to make Global Reference more nuanced. Keep up the good work!
You could setup more specific rules: learn.microsoft.com/en-us/nuget/consume-packages/Central-Package-Management#central-package-management-rules as an option. Based on how your items are setup
![CAMPปลิ้น | EP.83[2/2] ประสบการณ์ขนหัวลุกจากตำนานวงการผี!](http://i.ytimg.com/vi/T_kFecQw7Ds/mqdefault.jpg)
I already knew about CPM, but not GlobalPackageReference. Thanks for sharing!
Me either! so cool!
Great feature James. Will do it tomorrow on my projects😍
Noice! let me know how it goes!!!!
This really makes massive projects so much easier! Thank you.
I haven't seen this before. Thanks for the insight!
Was new to me as well even though it has been out for a while. So many nice things... sometimes just discovering them is the problem lol.
Very useful. Thank you sir 🙏
I’ve learned something new. Thanks
Super!... Useful tips!
Awesome :o that is exactly what i need currently. Thanks a lot
Very useful video! Thanks!
Glad it was helpful!
Does:
dotnet add package Some.Package
I'm not clear how any of this is better than right-clicking the solution and choosing Manage NuGet Packages for Solution and just letting it update all the packages itself. Does it speed up AZDO build pipelines or something? I guess as Microsoft pushes people away from Visual Studio and towards VSCode and the command line, this will come in handy. Especially on Mac. Maybe I answered my own question.
I guess it can be for cleaner commits. Committing in a centralised place rather than across multiple project files but it's only a very small benefit. The 2nd part of having a global package just seems nice for cleanliness also
That and also I think just managing everything in 1 place, no need to open every since csproj. Imagine super large projects, just saves time.
@@JamesMontemagno but it's easier to manage nuget packages for solution using the GUI rather than adding manually the references in the props file so I'm not sure if you are saving time. It also means that I cannot use the GUI anymore to install new nugets right?
@@almis6470 Yea, the bigger problem is that if someone doesn’t know this feature is being used and they’re used to looking at versions in the GUI, they are going to get confused real fast. The feature seems half baked because of this and may actually waste more time than it saves. You also have to wonder how committed Microsoft is in that case since they’ve disabled these type of half supported solution level flags and features in the past.
@@JamesMontemagno But we already have Consolidate on the Manage packages for SOlution tab for that as well
Awesome video, so I subscribed first. But, reading the description, and finding out your a Clevelander!. Me too 😆👍!
Seriously nice feature.
So what is the added value of central package management vs. just pressing "Update" in IDE for solution?
Great stuff! However, one question is coming to my mind...what if each project have different set of packages?
That is what I showed first, you just don't specify a PackageReference per usual in the project. You just are centralizing all the versions.
If ALL of your nugets are different in each project... then up to you if you want a more central place.
@@JamesMontemagno not very clear still... do you mean the moment you showed somthing with a star like 8.0.0-* ? or somethings else... if you mean the star, then do we set the Version attribute inside of the projects which use different versions? will system not give us error then?
Actually I have all the versions same but I was curious as well and this comment brought my attention to it
@@JamesMontemagno So GlobalPackageReference is mostly useful for packages that will be in all you projects. If I have a solution with 60 projects I would not expect all of the to use FluentValidation. Does this Global reference mean the package is considered for compiling/linking your code, hence it is taken on a ride in building *all* you projects in that solution?
PackageVersion is in essence replacing the Manage Packages for solution and then use the Consolidate option? You also did not show how you would then Update a package to a newer version, can I still go the any project and say Update to latest, and VS will default to updating the Directory.Packages.props instead of adding a version to that project. Or is this a manual editing task at this time?
Is the nuget package manager taking into consideration the GlobalPackageReference when updating or adding a dependency so that it doesn't add the ref in the given project's csprojs ?
You can`t use "*" in globally defined package version - Error NU1011 Centrally defined floating package versions are not allowed
So the PackageVersion is maintained per solution? Or could I move it up even more. As you explained we have an applicaiton consisting of multiple solutions all generating different programe and we either use multiple solutions, or solution filters. Would you need to have the Directory.Packages.props file at the solution file level, of when I use diferent subfolder for different solutions I can put it in the repo root folder for instance.
Should have read the Docs, yes you can put these files up to the repo root for more global use.
Does this work with solutions with .NET Framework projects, or would they have to be upgraded to .NET 6?
Need to use .NET 6+ and new project system
How does it work with Maui app? Where can I remove versions for packages that are under platforms?
I put a link in the video description on details. There is a lot of work in and around .NET 8 in RC2 for it
@@JamesMontemagno Yeah, it looked complicated 🫣 Thanks for your response!
🤯🤯🤯 👏👏👏
Wildcard package versioning is not supported. A big disadvantage. Once enabled, all package versions are to be defined only in this file. And only version # can only be overridden if necessary. Reference cannot be defined directly at the project level, even if needed in only one project. A cumbersome process. It should be rather a hierarchical definition.
Hey James, great video on!
While I'm definitely a fan of managing packages at the solution level, I do have some reservations about the Global Reference feature. While it streamlines things, it seems a bit too broad for my liking.
For example, it would be awesome if we could set Global References specific to types of projects, like Tests. I know we can achieve something similar with PackageReference, but the Global Reference feature seems like it might be a step too far in generalizing dependencies.
Would love to know your thoughts on this or if there are workarounds to make Global Reference more nuanced. Keep up the good work!
You could setup more specific rules: learn.microsoft.com/en-us/nuget/consume-packages/Central-Package-Management#central-package-management-rules as an option. Based on how your items are setup
😊😊😊❤