Centrally manage dependencies and its versions

[Nirmal4G]

Info

Fixes CommunityToolkit/WindowsCommunityToolkit#4180 Extracted from CommunityToolkit/WindowsCommunityToolkit#4181

Changes

• Use Static Graph restore when applicable.
• Manage Packages Centrally using NuGet's CPVM feature.

Know more about NuGet's Central Package Version Management (CPVM) feature.

Currently, NuGet package references are spread across project files. It is difficult to track versions and upgrade them properly. This patch enables NuGet's upcoming feature to manage package versions centrally using Directory.Packages.props with the following item spec to store a package version.

  <ItemGroup>
    <PackageVersion Include="Vendor.Awesome.Package" Version="11.0.0" />
  </ItemGroup>

PR Checklist

• [x] Created a feature branch in your fork
• [x] Based off latest main branch of toolkit
• [x] PR doesn't include merge commits (always rebase on top of our main)
• [x] Header has been added to all new source files (ran build/Update-Headers.ps1)
• [x] Tested code with current supported SDKs
• [x] Contains NO breaking changes
• [x] Code follows all style conventions

Notes

• Rebase merge if possible.
• Wait for my refactor PR to be merged!
• When merging, please update the commit title to PR title instead of the default Merge pull request #xxxx from repo/branch, and commit message to either PR message or messages of individual commits. The auto-merge option does this by default.

[Nirmal4G]

There's a change in how we pack the SourceGen project into the parent project in this patch. I hope to create a new PR for that change but I will test it here before I do that. That change was made in response to this feature.

I don't want to update the workaround just to unblock the PR. This patch can wait as it needs support from VS IDE. As far as I know, v17.2 is the target to enable central package versioning in the NuGet PM UI.

[Nirmal4G]

Please merge this only after merging #85 and #220 as it depends on some changes from those PRs. All the 3 PRs are correlated since the changes cascade into the other.

[Nirmal4G]

Initially, I wanted just two PRs, one for refactoring and another for central versioning but MVVM Changes are important enough to warrant an issue and PR of their own. But I can create a separate PR for common paths, if needed.

We can do artifacts if that's preferred strongly but having a build, publish and packages top-level directories makes sense, IMEX. And the tilde ~ symbol literally makes it top-level in the directory listing. That's why I choose this pattern.

My thoughts… tl;dr M$FT is lazy!

I experimented with Arcade SDK and found it lacking in so many ways, especially the defaults could've been better, IMHO! Explaining all the reasons why current defaults of .NET SDK is bad for large scale projects, would either need a blog series or a presentation talk!! 😂 Yeah, it's that bad!!! 🤦

And before you go on about how Microsoft uses Arcade for entire .NET Foundation projects, let me tell you, Arcade is simple defaults, low-config, too-many things, highly opinionated and tuned specific to only Microsoft managed .NET Foundation projects. It's goal is to take what M$FT repos would need and put them in a shared package so that everyone who needs it uses it without maintaining their own solution. It's not for general public.

I prefer M$FT products over others anyday but not a fan! I used to in the days of XP, Vista and 7 but not now. They have become lazy!

One thing you have to know about M$FT is that they do relatively minimal enough to get the project going since it requires a low maintainance cost, less work. It's how most corporates work and M$FT does it even less than others. They don't plan far ahead which is why most of their initiatives fail after a point in time.

It's like this, with M$FT, the final things they produce, be it software or hardware, they don't scale well, since the requirements are limited even though the ideas and design are good. Also, Exceptions are not examples!!