.NET Framework-ში მორგებული პროქსი მოდულის ჩატვირთვა
შეამოწმეთ ტიპების ჩატვირთვა, შესრულებადი ფაილის კონფიგურაცია და მოთხოვნის გადაფარვები, როცა defaultProxy მოდული უმოქმედოდ გამოიყურება.
.NET Framework აპლიკაციისთვის დაარეგისტრირეთ პროქსი მოდული configuration/system.net/defaultProxy-ის ქვეშ:
<defaultProxy>
<module type="Company.Network.RoutingProxy, Company.Network" />
</defaultProxy>პირველი სახელი არის ტიპი, ხოლო მეორე — მისი ასამბლეის იდენტობა, არა DLL-ის გზა. ასამბლეა და დამოკიდებულებები უნდა ჩაიტვირთოს აპლიკაციის ჩვეულებრივი წესებით.
შეამოწმეთ ორი კარიბჭე. პირველ რიგში, runtime-მა უნდა შექმნას საჯარო ტიპი, რომელიც ახორციელებს IWebProxy-ს პარამეტრების გარეშე კონსტრუქტორის მეშვეობით. შეინახეთ შიდა გამონაკლისები ჩატვირთვის ან აგების წარუმატებლობიდან; ისინი წინ უსწრებენ ნებისმიერ პროქსი TCP კავშირს. სამუშაო მაგიდის გამოშვებისთვის დაადასტურეთ, რომ რეგისტრაციამ მიაღწია შესრულებადი ფაილის განლაგებულ კონფიგურაციას. ClickOnce-ით შეადარეთ აგებული, გამოქვეყნებული და დაინსტალირებული .exe.config. კლასის ბიბლიოთეკის App.config ჩვეულებრივ არ აკონფიგურირებს მის ჰოსტ პროცესს.
მეორე, მოთხოვნამ უნდა გამოიყენოს ეს ნაგულისხმევი. პროქსის მკაფიო მინიჭებამ შეიძლება შეცვალოს ის, და სხვა HTTP სტეკმა შეიძლება არ წაიკითხოს ეს კონფიგურაციის მოდელი. მოდულის შიგნით, GetProxy და IsBypassed საჭიროებენ თანმიმდევრულ გადაწყვეტილებებს, აბსოლუტური პროქსი URI-ით, რომელიც იყენებს სწორ სქემას და პორტს.
თანმიმდევრული გახადეთ რწმუნებათა ქცევაც. Getter, რომელიც ქმნის ხისტად კოდირებულ ანგარიშს და უგულებელყოფს თავის setter-ს, შეიძლება ჩაშალოს შემდგომი კონფიგურაცია წარმატებული ჩატვირთვის შემდეგაც.
ეს არის ტექნიკური მომსახურების მექანიზმი .NET Framework-ისთვის. გამოიყენეთ ქსელის კლიენტის მიერ მხარდაჭერილი პროქსი კონფიგურაცია მიმდინარე .NET-ში, იმის ნაცვლად, რომ ელოდოთ ამ ძველი system.net რეგისტრაციის მართვას ყველა HttpClient-ზე.