.NET Framework-এ একটি কাস্টম প্রক্সি মডিউল লোড করা

.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 সহ।

শংসাপত্রের আচরণও সামঞ্জস্যপূর্ণ করুন। একটি গেটার যদি হার্ডকোড করা অ্যাকাউন্ট তৈরি করে এবং তার সেটার উপেক্ষা করে, তবে লোডিং সফল হওয়ার পরেও পরবর্তী কনফিগারেশন ব্যর্থ হতে পারে।

এটি .NET Framework-এর জন্য একটি রক্ষণাবেক্ষণ ব্যবস্থা। বর্তমান .NET-এ নেটওয়ার্কিং ক্লায়েন্টের সমর্থিত প্রক্সি কনফিগারেশন ব্যবহার করুন, এই লিগ্যাসি system.net নিবন্ধন প্রতিটি HttpClient নিয়ন্ত্রণ করবে বলে আশা না করে।