Simplify accessing assembly versions

[0xced]

Use the same method everywhere an assembly version is required in order not to useFileVersionInfo.GetVersionInfo directly, which is not compatible with single file applications whose assembly.Location always return an empty string. (It was still used directly in the AuthProcessor class)

Also, use GetCustomAttribute()?.Version with a question mark before acessing the .Version property in order to fallback to version on disk rather than crashing with a null reference exception. (The ? was missing in both Microsoft.PowerPlatform.Dataverse.Client.ServiceClient.SdkVersionProperty and Microsoft.PowerPlatform.Dataverse.Client.Auth.TokenCache.FileBackedTokenCacheHints.FileBackedTokenCacheHints)

[MattB-msft]

Thanks again for your contribution :) We will look into and review this.

[MattB-msft]

We have reviewed this one and are not going accept this one. We will consider doing some refactoring of where the versions come from now that we have included parts of the server in this client, however there are several versions we care about from different libs in the client, and we use them for a few different things.

Thanks for calling it out though.

[0xced]

I think this pull request did not change the current behaviour, it only reduced code duplication. But I may be wrong, it's hard to test all the affected code paths.

Anyway, could you please at least fix the AuthProcessor class at line 434?

FileVersionInfo.GetVersionInfo(typeof(Xrm.Sdk.Organization.OrganizationDetail).Assembly.Location).FileVersion;

This is preventing single-file deployment because FileVersionInfo.GetVersionInfo("") throws System.ArgumentException: The path is empty. (Parameter 'path') when the path is empty, which is exactly what happens when deployed as a single file executable.

[MattB-msft]

Yep, we will fix that, there are several place we need to move away from file versions.

[MattB-msft]

We have updated this. see fix #272