`publicKeyToken` and `culture` attributes changing order when binding redirects are updated vs regenerated

[julealgon]

I noticed this by complete accident after performing a full refresh of my binding redirects as described here:

• Add GeneratedBindingRedirectsAction option that fully refreshes all binding redirects #90

After performing that "cleanup" change and merging my code, the very next NuGet package update that I did resulted in the binding being updated, but the publicKeyToken and culture attributes had their places swapped.

Here is an example of the diff after upgrading the Microsoft.Identity.Client package and rebuilding my project:

If I then go ahead and delete the section again, and let it regenerate from scratch, I get this diff:

My assumption here is that this update is being performed by nuget.exe (unsure here), and that tool is enforcing this particular order (culture, then publicKeyToken), whereas this SDK is writing the entries using the inverse order (publicKeyToken then culture).

I'd like to propose that the logic in the SDK be updated to write the nodes using the same attribute order that nuget.exe uses so as to minimize diffs when making these updates.

My assumption is that this would be a trivial update.

[CZEMacLeod]

@julealgon The SDK uses the base Microsoft SDK to do the Binding Redirects - so you would have to get MS to adjust their code.

https://github.com/dotnet/msbuild/blob/00b81e71d503ae21780f97f7f5206821e696a5f9/src/Tasks/AssemblyDependency/GenerateBindingRedirects.cs#L90-L104