Azure Notification Hubs .NET: якая налада проксі перамагае?

Наладзьце NotificationHubSettings.Proxy або перададзены HTTP-транспарт, улічваючы прыярытэт HttpClient і MessageHandler у канструктары.

У 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);

Радок злучэння і назва вузла застаюцца канфігурацыяй службы. Публічны HTTP-эндпойнт са Спіс HTTP-проксі можа запоўніць адрас WebProxy у стандартным шляху стварэння.

У гэтым канструктары ёсць правіла чарговасці:

  1. Перададзены HttpClient выкарыстоўваецца першым.
  2. Інакш перададзены MessageHandler стварае HTTP-кліент.
  3. Інакш Proxy стварае HttpClientHandler, наладжаны на проксі.
  4. Калі нічога не перададзена, канструктар стварае свой стандартны HTTP-кліент.

Калі праграма ўжо перадае HttpClient або MessageHandler, наладзьце проксі гэтага транспарту, а не спадзявайцеся, што асобная ўласцівасць Proxy яго перазапіша.

Для ўліковага запісу проксі задайце ўліковыя даныя ў WebProxy да стварэння. Яны аўтэнтыфікуюцца на пасярэдніку, а не ў Notification Hub.

Старыя прыклады называюць NotificationHubClientSettings. Супастаўляйце тып налад і канструктар, якія прапануе ўсталяваны пакет, замест таго каб змешваць гэтую назву ў API, што чакае NotificationHubSettings.

Падобныя артыкулы