WorkloadCollection cleanup

[MiYanni]

Related: #35859

Summary

Daniel had suggested that I put the WorkloadCollection alias into the global usings instead of redefining it in multiple .cs files. To do that, I needed it to be defined where the types exist; meaning, you can't just put it in the Directory.Build.props at the root of the repo as every project doesn't have access to WorkloadId or WorkloadDefinition. Therefore, I just added a Directory.Build.props for them to the 2 projects I know contain these classes, dotnet and dotnet.Tests.

[nagilson]

I love it 🔥

[dsplaisted]

Instead of creating a Directory.Build.props file for single projects, why don't you put the Using item in the .csproj files themselves?

[MiYanni]

@dsplaisted

Instead of creating a Directory.Build.props file for single projects, why don't you put the Using item in the .csproj files themselves?

For whatever reason, my brain thought, "Well, let me put these with the other Usings in Directory.Build.props. Oh, right. It won't work there. Well I'll just split it out where it will work." Also, I've only every used these Using items in a Directory.Build.props file, so I didn't know if that affected anything. Like, I didn't look at the binlog to see when the generation task/target happens for this stuff.

But this is much better to have them in the .csproj instead of separate files. Updated the PR.

Edit: Ahhhh, found it in the docs: