برای یک برنامهٔ .NET Framework، ماژول پروکسی را زیر configuration/system.net/defaultProxy ثبت کنید:

<defaultProxy>
  <module type="Company.Network.RoutingProxy, Company.Network" />
</defaultProxy>

نام اول نوع است و دومی هویت اسمبلی آن، نه مسیر DLL. اسمبلی و وابستگی‌ها باید طبق قواعد عادی برنامه بارگذاری شوند.

دو دروازه را بررسی کنید. نخست، زمان اجرا باید یک نوع عمومی را که IWebProxy را پیاده‌سازی می‌کند، از طریق سازندهٔ بدون پارامتر بسازد. استثناهای درونی ناشی از شکست بارگذاری یا ساخت را نگه دارید؛ آن‌ها پیش از هر اتصال TCP پروکسی رخ می‌دهند. برای نسخهٔ دسکتاپ، تأیید کنید که ثبت به پیکربندی مستقرشدهٔ فایل اجرایی رسیده است. با ClickOnce، فایل .exe.config ساخته‌شده، منتشرشده و نصب‌شده را مقایسه کنید. App.config یک کتابخانهٔ کلاس معمولاً فرایند میزبان خود را پیکربندی نمی‌کند.

دوم، درخواست باید از آن پیش‌فرض استفاده کند. یک انتساب صریح پروکسی می‌تواند آن را جایگزین کند، و پشتهٔ HTTP دیگری ممکن است این مدل پیکربندی را نخواند. درون ماژول، GetProxy و IsBypassed به تصمیم‌های سازگار نیاز دارند، با یک URI مطلق پروکسی که از طرح و درگاه درست استفاده کند.

رفتار اعتبارنامه‌ها را نیز سازگار کنید. یک getter که حساب سخت‌کدشده می‌سازد و setter خود را نادیده می‌گیرد می‌تواند پیکربندی بعدی را حتی پس از بارگذاری موفق از کار بیندازد.

این یک سازوکار نگهداری برای .NET Framework است. در .NET کنونی از پیکربندی پروکسی پشتیبانی‌شده توسط کلاینت شبکه استفاده کنید، نه اینکه انتظار داشته باشید این ثبت قدیمی system.net بر هر HttpClient حاکم باشد.

مقالات مرتبط