Azure Notification Hubs .NET: أي إعداد وكيل يفوز؟

في واجهة Notification Hubs .NET API عند استخدام NotificationHubSettings، يمكن توريد وكيل أثناء إنشاء العميل:

var settings = new Microsoft.Azure.NotificationHubs.NotificationHubSettings
{
    Proxy = new System.Net.WebProxy("http://proxy.example:8080")
};
var hub = new Microsoft.Azure.NotificationHubs.NotificationHubClient(
    hubConnectionString, hubName, settings);

يبقى سلسلة الاتصال واسم hub هما إعداد الخدمة. يمكن لنقطة نهاية HTTP عامة من قائمة وكلاء HTTP أن تملأ عنوان WebProxy في مسار الإنشاء الافتراضي.

ثمة قاعدة ترتيب في ذلك المُنشئ:

1. يُستخدم HttpClient المورَّد أولًا.
2. وإلا يُنشئ MessageHandler المورَّد عميل HTTP.
3. وإلا يُنشئ Proxy معالج HttpClientHandler مهيأً للوكيل.
4. وإذا لم يُورَّد شيء، يُنشئ المُنشئ عميل HTTP الافتراضي.

إذا كان التطبيق يورّد HttpClient أو MessageHandler بالفعل، فاضبط وكيل ذلك النقل بدل أن تتوقع أن تتجاوزه خاصية Proxy المنفصلة.

لحساب وكيل، عيّن بيانات الاعتماد على WebProxy قبل الإنشاء. فهي تصادق لدى الوسيط لا لدى Notification Hub.

تذكر أمثلة أقدم NotificationHubClientSettings. طابق نوع الإعدادات والمُنشئ الذي تعرضه الحزمة المثبتة بدل خلط ذلك الاسم في واجهة تتوقع NotificationHubSettings.