NuGet بحالی کے لیے فارورڈ پراکسی اکاؤنٹ اور نجی فیڈ اکاؤنٹ دونوں درکار ہو سکتے ہیں۔ یہ طے کرنے کے لیے کہ کون سی ترتیب کا معائنہ کرنا ہے، جواب استعمال کریں:

مشاہدہیہاں سے شروع کریں
پراکسی 407 واپس کرتی ہےفارورڈ پراکسی تک پہنچنے کے لیے استعمال ہونے والا راستہ اور اکاؤنٹ
پیکیج ماخذ 401 واپس کرتا ہےفیڈ کی توثیقی ترتیب
جواب سے پہلے کنکشن یا TLS ناکام ہوتا ہےاینڈ پوائنٹ، منتقلی اور سرٹیفکیٹ کے شواہد

فیڈ ٹوکن پراکسی کے 407 کا جواب نہیں دے سکتا۔ اسی طرح، جواب سے پہلے کنکشن یا TLS کی ناکامی نے یہ ثابت نہیں کیا کہ کون سا پاس ورڈ غلط ہے۔

پراکسی کو فیڈ سے الگ ترتیب دیں

NuGet کا پراکسی اندراج config کے تحت آتا ہے۔ بغیر سرایت شدہ اسناد کے راستے کے لیے:

<configuration>
  <config>
    <add key="http_proxy" value="http://proxy.example:8080" />
  </config>
</configuration>

اس مثال کو مناسب موجودہ ترتیب میں ضم کریں۔ ایسی عوامی فیڈ کے لیے جہاں عوامی ثالثوں کی اجازت ہے، HTTP پراکسی فہرست اس اسناد سے پاک راستے کے لیے امیدوار پیش کرتی ہے۔ پیکیج ماخذ اپنے حصے میں رکھیں؛ فیڈ کے URL کو عمومی پراکسی پتے سے بدلنا ثالث سے پیکیج طلب کرتا ہے۔

دستاویز شدہ http_proxy.password قدر خفیف ہے۔ اُس خانے میں سادہ متن لکھنے یا کسی دوسری مشین سے خفیف دکھنے والی قدر کو قابلِ منتقلی اسناد کی صورت سمجھ کر نقل کرنے کے بجائے معاون ترتیب کے اوزار استعمال کریں۔

اُس بحالی کا معائنہ کریں جو واقعی ناکام ہوتی ہے

کلائنٹ، صارف اور لانچ ماحول کا نام لیں، پھر اُس کا مؤثر ترتیبی درجہ بندی تلاش کریں۔ صارف، مشین اور حل کی ترتیبات حصہ ڈال سکتی ہیں۔ پرانی devenv.exe.config درستی کسی مخصوص Visual Studio عمل سے متعلق ہے؛ یہ ثابت نہیں کرتی کہ کمانڈ لائن بحالی یا بلڈ سروس کیا پڑھتی ہے۔ فرسودہ پراکسی اندراج تلاش کرتے ہوئے کام کرنے والے پیکیج ماخذ اور پالیسی محفوظ رکھیں۔

توثیق کے کام کرنے کے بعد، بعد میں ناکام ہونے والے کسی بھی URL کی پیروی کریں۔ فیڈ میٹا ڈیٹا اور پیکیج کا مواد مختلف اینڈ پوائنٹ استعمال کر سکتے ہیں، اس لیے ایک قبول شدہ درخواست پوری بحالی کے راستے کو ثابت نہیں کرتی۔ اِسے درست کرتے ہوئے معمول کی پیکیج دستخط اور TLS توثیق برقرار رکھیں۔

متعلقہ مضامین