بازیابی NuGet می‌تواند هم به حساب پروکسی پیش‌رو و هم به حساب فید خصوصی نیاز داشته باشد. از پاسخ استفاده کنید تا تصمیم بگیرید کدام پیکربندی را بررسی کنید:

مشاهدهاز اینجا شروع کنید
پروکسی 407 برمی‌گرداندمسیر و حسابی که برای رسیدن به پروکسی پیش‌رو استفاده می‌شود
منبع بسته 401 برمی‌گرداندپیکربندی احراز هویت فید
اتصال یا TLS پیش از پاسخ شکست می‌خوردشواهد مربوط به نقطهٔ پایانی، انتقال و گواهی

توکن فید نمی‌تواند به خطای 407 پروکسی پاسخ دهد. به همین ترتیب، شکست اتصال یا TLS پیش از پاسخ مشخص نکرده است که کدام گذرواژه اشتباه است.

پروکسی را جدا از فید پیکربندی کنید

ورودی پروکسی در NuGet زیر config قرار می‌گیرد. برای مسیری بدون اعتبارنامهٔ جاسازی‌شده:

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

این نمونه را در پیکربندی موجود مناسب ادغام کنید. برای فید عمومی که در آن واسطه‌های عمومی مجاز است، فهرست پروکسی HTTP گزینه‌ای برای این مسیر بدون اعتبارنامه ارائه می‌دهد. منابع بسته را در بخش خودشان نگه دارید؛ جایگزینی نشانی فید با یک نشانی پروکسی عمومی از واسطه می‌خواهد بسته‌ها را بیاورد.

مقدار مستند http_proxy.password رمزگذاری شده است. از ابزارهای پیکربندی پشتیبانی‌شده استفاده کنید، نه اینکه متن آشکار در آن فیلد بنویسید یا مقداری را که رمزگذاری‌شده به نظر می‌رسد از ماشین دیگری به‌عنوان قالبی قابل‌حمل برای اعتبارنامه کپی کنید.

همان بازیابی‌ای را بررسی کنید که واقعاً شکست می‌خورد

کلاینت، کاربر و محیط راه‌اندازی را نام ببرید، سپس سلسله‌مراتب پیکربندی مؤثر آن را پیدا کنید. تنظیمات کاربر، ماشین و راه‌حل می‌توانند سهم داشته باشند. اصلاح قدیمی devenv.exe.config به یک فرایند مشخص Visual Studio مربوط است؛ مشخص نمی‌کند که بازیابی خط فرمان یا سرویس ساخت چه چیزی را می‌خواند. هنگام یافتن یک ورودی پروکسی منسوخ، منابع بسته و خط‌مشی‌های کارآمد را حفظ کنید.

پس از اینکه احراز هویت کار کرد، هر نشانی‌ای را که بعداً شکست می‌خورد دنبال کنید. فرادادهٔ فید و محتوای بسته می‌توانند از نقاط پایانی متفاوت استفاده کنند، بنابراین یک درخواست پذیرفته‌شده مسیر کامل بازیابی را مشخص نمی‌کند. هنگام اصلاح آن، اعتبارسنجی معمول امضای بسته و TLS را حفظ کنید.

مقالات مرتبط