თუ განვითარების build მუშაობს, მაგრამ მისი ClickOnce გამოშვება 407-ს აბრუნებს, რწმუნებების შეცვლამდე შეამოწმეთ, შეიცავს თუ არა გამოშვება შესრულებადი ფაილის განზრახ კონფიგურაციას.

შემოწმების წერტილირა შევადაროთ
Build-ის გამოსავალიშესრულებადი ფაილის სწორად დასახელებული კონფიგურაცია: Reports.exe.config Reports.exe-ისთვის
პუბლიკაციის გამოსავალიამ ფაილის შიგთავსი და აპლიკაციის ფაილების ჩართვის პარამეტრები
დაზარალებული ინსტალაციაგამოქვეყნებული ვერსია, რომელიც ამ მომხმარებელმა რეალურად მიიღო

App.config არის წყარო .NET Framework-ის სამუშაო მაგიდის პროექტში. მისი რედაქტირება არ ამტკიცებს, რომ ინსტალირებულმა აპლიკაციამ მიიღო შედეგად მიღებული .exe.config.

მემკვიდრეობითი აპლიკაციისთვის, რომელიც განზრახულია გამოიყენოს სისტემის პროქსი Windows-ის მიმდინარე რწმუნებებით, ფრაგმენტი შეიძლება იყოს:

<system.net>
  <defaultProxy useDefaultCredentials="true">
    <proxy usesystemdefault="true" />
  </defaultProxy>
</system.net>

მოათავსეთ ის არსებული configuration ფესვის ქვეშ, შეუსაბამო პარამეტრების შენარჩუნებით. ეს არის .NET Framework-ის ქსელური კონფიგურაციის მოდელი და არა პარამეტრი ყველა თანამედროვე .NET კლიენტისთვის.

თუ ინსტალირებული ფაილი სწორია, შემდეგ მიჰყევით პროცესის იდენტობას და მარშრუტს. ნაგულისხმევი რწმუნებები არის ის, რაც ხელმისაწვდომია გაშვებული პროცესისთვის; ისინი პროქსის ნებართვას არ იძლევიან. აშკარა აპლიკაციური პროქსი ასევე შეიძლება ჩაანაცვლოს ნაგულისხმევი. დაკარგული გამოქვეყნებული კონფიგურაცია და უარყოფილი ავთენტიფიკაცია ორივე 407-ის მსგავსი შეიძლება იყოს, მაგრამ სამი ფაილის შედარება წყვეტს, არის თუ არა მიწოდება პირველი შეკეთება.

დაკავშირებული სტატიები