NuGet 407 बनाम 401: प्रोक्सी लगइन कि निजी फिडको प्रमाणहरू?

NuGet पुनर्स्थापनाका लागि फर्वार्ड-प्रोक्सी खाता र निजी फिड खाता दुवै आवश्यक हुन सक्छ। कुन कन्फिगरेसन जाँच्ने भनी निर्णय गर्न प्रतिक्रिया प्रयोग गर्नुहोस्:

फिड टोकनले प्रोक्सीको 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 प्रमाणीकरण कायम राख्नुहोस्।