Ստուգեք հրապարակված .exe.config-ը, երբ ClickOnce-ը կորցնում է proxy-ի կարգավորումը
Ստուգեք տեղակայված գործարկվող ֆայլի կազմաձևը, երբ .NET Framework-ի proxy-ի փոփոխությունը աշխատում է տեղում, բայց անհետանում է ClickOnce-ի տեղադրման մեջ:
Եթե մշակման բիլդը աշխատում է, բայց դրա ClickOnce թողարկումը վերադարձնում է 407, նախքան հավատարմագրերը փոխելը ստուգեք՝ արդյոք թողարկումը պարունակում է նախատեսված գործարկվող ֆայլի կազմաձևը։
| Ստուգման կետ | Ինչ համեմատել |
|---|---|
| Բիլդի ելք | Գործարկվող ֆայլի ճիշտ անունով կազմաձևը՝ Reports.exe.config Reports.exe-ի համար |
| Հրապարակման ելք | Այդ ֆայլի բովանդակությունը և հավելվածի ֆայլերի ներառման կարգավորումները |
| Ազդված տեղադրում | Հրապարակված տարբերակը, որն այդ օգտատերը փաստացի ստացել է |
App.config-ը աղբյուրն է .NET Framework-ի աշխատասեղանային նախագծում։ Այն խմբագրելը չի ապացուցում, որ տեղադրված հավելվածը ստացել է արդյունքում ստացված .exe.config-ը։
Ժառանգված հավելվածի համար, որը նախատեսված է օգտագործել համակարգի proxy-ն Windows-ի ընթացիկ հավատարմագրերով, հատվածը կարող է լինել՝
<system.net>
<defaultProxy useDefaultCredentials="true">
<proxy usesystemdefault="true" />
</defaultProxy>
</system.net>Տեղադրեք այն գոյություն ունեցող configuration արմատի տակ՝ պահպանելով չառնչվող կարգավորումները։ Սա .NET Framework-ի ցանցային կազմաձևման մոդելն է, ոչ թե յուրաքանչյուր ժամանակակից .NET հաճախորդի կարգավորում։
Եթե տեղադրված ֆայլը ճիշտ է, ապա հետևեք գործընթացի ինքնությանը և ուղուն։ Լռելյայն հավատարմագրերն այն են, որոնք հասանելի են աշխատող գործընթացին․ դրանք proxy-ի թույլտվություն չեն տալիս։ Բացահայտ հավելվածային proxy-ն նույնպես կարող է փոխարինել լռելյայնին։ Բացակայող հրապարակված կազմաձևը և մերժված նույնականացումը երկուսն էլ կարող են 407-ի տեսք ունենալ, բայց երեք ֆայլերի համեմատությունը որոշում է՝ արդյոք առաքումը առաջին վերանորոգումն է։