Defaults communication between SDK & IDEs

[jonpryor]

Scenario

In Xamarin.Android 8.3 (d15-7), we're changing the default SSL/TLS Implementation ($(AndroidTlsProvider)) value so that BTLS is enabled by default; see 6264be7.

That's all well and good, but what about the end-developer experience? Visual Studio for Mac shows these drop-downs:

What is Default?

The end-developer could hover their mouse of the ? on the right, but (1) that's extra work, and (2) in the case of SSL/TLS Implementation, the ? is useless: there is no description of what "Default" means.

¯_(ツ)_/¯

Additionally, the Xamarin.Android SDK team may want to change what "Default" means in the future, e.g. revert an "empty" $(AndroidTlsProvider) value to mean the "Managed TLS 1.0" while the meaning of $(AndroidClientHandler)=='' is altered.

Solution

The proposal is to update Xamarin.Android.Common.props -- which the IDE already knows about and has access to -- so that it specifies what the default is and what it means.

The proposal is for two additional MSBuild properties:

• $(AndroidDefaultClientHandlerLabel): The label for the default HttpClient Implementation label.
• $(AndroidDefaultTlsProviderLabel): The label for the default SSL/TLS Implementation label.

For example, at present we'd have:

<AndroidDefaultClientHandlerLabel>Default (HttpClientHandler)</AndroidDefaultClientHandlerLabel>
<AndroidDefaultTlsProviderLabel>Default (BTLS)</AndroidDefaultTlsProviderLabel>

The value of these properties would be used instead of Default in the appropriate drop-down boxes within the IDEs.

Alternative take: Instead of "just" specifying the default value, we could provide all the supported values in a ;-and-:-delimited list: ; between descriptions, and : to separate label names from .csproj values:

<AndroidDefaultClientHandlerLabels>
    Default (HttpClientHandler):;
    Managed (HttpClientHandler):System.Net.Http.HttpClientHandler, System.Net.Http;
    AndroidClientHandler:Xamarin.Android.Net.AndroidClientHandler
</AndroidDefaultClientHandlerLabels>
<AndroidDefaultTlsProviderLabels>
    Default (BTLS):;
    Native TLS 1.2+:btls;
    Managed TLS 1.0:legacy;
</AndroidDefaultTlsProviderLabels>

Discussion

The downside with either of these solutions is that it hardcodes localizable strings into an unlocalizable file. "Default" (should?) be localized. Perhaps the above solutions are "fine" and we just need to pass the resulting values through e.g. gettext() (or however the IDEs handle localization), or perhaps some other solution is needed.

[sgmunn]

I don't think we'd want it to be the label that is shown because that won't be translated - the ide could probably just pre-pend the "default" localised text to whatever the default value is.

[mhutch]

Note also that VS already has a mechanism for the targets to provide property labels e.g. https://github.com/dotnet/project-system/blob/master/src/Microsoft.VisualStudio.ProjectSystem.Managed/ProjectSystem/Rules/None.xaml

[mhutch]

TBH I think displaying defaults is a general problem for all properties, not just these ones, and particularly so for modern SDK style projects. I wonder whether we could handle it in a more generic way /cc @maryanne-exe @hbons

[joj]

We can use that mechanism that already exists. I need to make sure I can read it from our side.

[hbons]

Agree with @sgmunn. We've been doing this in some places and we should make this a common pattern.

[joj]

@mhutch do you know how the NPS guys are localizing that?

[mhutch]

I don't, sorry

[dotnet-policy-service]

We suspect this issue is stale and no longer relevant. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will undo this process.

[dotnet-policy-service]

This issue will now be closed since it had been marked "possibly-stale" but received no further activity in the past 14 days. It is still possible to reopen or comment on the issue, but please note that the issue will be locked if it remains inactive for another 30 days.