ClickOnce പ്രോക്സി ക്രമീകരണം നഷ്ടപ്പെടുമ്പോൾ പ്രസിദ്ധീകരിച്ച .exe.config പരിശോധിക്കുക
.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 പോലെ തോന്നാം, പക്ഷേ മൂന്ന് ഫയൽ താരതമ്യമാണ് ഡെലിവറിയാണോ ആദ്യ അറ്റകുറ്റപ്പണി എന്ന് തീരുമാനിക്കുന്നത്.