შეამოწმეთ გამოქვეყნებული .exe.config, როცა ClickOnce პროქსის პარამეტრს კარგავს
შეამოწმეთ განლაგებული შესრულებადი ფაილის კონფიგურაცია, როცა .NET Framework-ის პროქსის ცვლილება ლოკალურად მუშაობს, მაგრამ ClickOnce-ის ინსტალაციაში ქრება.
თუ განვითარების 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-ის მსგავსი შეიძლება იყოს, მაგრამ სამი ფაილის შედარება წყვეტს, არის თუ არა მიწოდება პირველი შეკეთება.