Správičky 2 813 Blogy 948 Fórum 18 712

Zásadné zmeny v ASP.NET 2.0 aplikáciách bežiacich v Integrated mode na IIS 7.0

duffyx - 22. 3. 2008 16:38 - 19198 views

Zásadné zmeny v ASP.NET 2.0 aplikáciách bežiacich v Integrated mode na IIS 7.0

Zdroj: Breaking Changes for ASP.NET 2.0 applications running in Integrated mode on IIS 7.0 od Mike Volodarsky

ASP.NET aplikácie na IIS 7.0 sú štandardne hostované v Integrated mode. Tento nový mód umožňuje obrovské množstvo vzrušujúcich scenárov, vrátane hodnotných možností ASP.NET, ako napr. Forms Authentication pre celú webovú aplikáciu a vývoj nových ASP.NET modulov, ktoré môžu využívať možnosti ako URL rewriting, logging, a ďalšie na úrovni IIS. Pre ďalšie informácie o integrácií ASP.NET a IIS 7.0 si možete pozrieť tento článok: ASP.NET integrácia s IIS 7.

Ako viete, s veľkou silou prichádza aj veľká zodpovednosť. Podobne, aj s vytváraním nových, viac výkonných ASP.NET aplikácií na IIS 7.0 prichádza zodpovednosť, že pri migrácií budú ASP.NET aplikácie pracovať správne. To bola hlavná výzva architektov jadra ASP.NET a v konečnom dôsledku sa im to úspešne podarilo. Veľké množstvo aplikácií by mali fungovať bez zmien.

Tento zoznam zmien môžete využiť pri nasadzování ASP.NET aplikácií na IIS 7.0 na Windows Vista SP1 a Windows Server 2008. Tieto zásadné zmeny sa týkajú len pri používaní ASP.NET Integrated mode.

Používanie ASP.NET Classic mode

IIS 7.0 taktiež ponúka schopnosť bežat ASP.NET aplikácie s použitím pôvodného ASP.NET Classic mode, ktorý pracuje na podobnom princípe ako ASP.NET na predchádzajúcich verziách IIS. Avšak, veľmi doporučujeme upraviť aplikácie tak, aby bežali v Integrated mode. Pri návrate ku Classic mode nebudete môct využívať výhody ASP.NET vylepšení v Integrated mode a vplyv budúcich možností z Microsoftu a spoločností tretích strán môže vyžadovať práve Integrated mode. Používanie Classic mode by mala byť poslednou možnosťou, pokiaľ nie je možné aplikáciu upraviť na beh v Integrated mode. Pre viac informácií ohľadne prechodu na Classic mode možete pozrieť v tomto článku: Zmena ASP.NET módu na IIS 7.0.

Chyby pri migrácií

Tieto chyby možu nastať pri zmene ASP.NET konfigurácie alebo migrácií na Integrated mode. IIS automaticky detekuje takúto konfiguráciu a vyhlási chybu vo forme výzvy migrácie Vašej aplikácie, alebo zmenu na Classic mode, pokiaľ nie je migrácia prijateľná.

1) ASP.NET aplikácie vyžadujú migráciu, pokiaľ je špecifikovaná konfigurácia v<httpModules> alebo <httpHandlers>

HTTP Error 500.22 / HTTP Error 500.23 - Internal Server Error

An ASP.NET setting has been detected that does not apply in Integrated managed pipeline mode.

Module: ConfigurationValidationModule
Notification: BeginRequest
Handler: PageHandlerFactory-Integrated
Error Code: 0x80070032

Most likely causes:

This application defines configuration in the system.web/httpModules section. / This application defines configuration in the system.web/httpHandlers section.

Things you can try:

  • Migrate the configuration to the system.webServer/modules section. You can do so manually or by using AppCmd from the command line - for example, %SystemRoot%\system32\inetsrv\appcmd migrate config "Default Web Site/". Using AppCmd to migrate your application will enable it to work in Integrated mode, and continue to work in Classic mode and on previous versions of IIS.
  • If you are certain that it is OK to ignore this error, it can be disabled by setting system.webServer/validation@validateIntegratedModeConfiguration to false.
  • Alternatively, switch the application to a Classic mode application pool - for example, %SystemRoot%\system32\inetsrv\appcmd set app "Default Web Site/" /applicationPool:"Classic .NET AppPool". Only do this if you are unable to migrate your application.

Táto chyba nastáva keď sú definované <httpModules>/<httpHandlers> vo web.config. Tieto nastavenia by mali byť definované v časti <modules>/<handlers> v Integrated mode.

Riešenie:

1) Musíte premigrovať konfiguráciu do system.webServer/modules alebo system.webServer/handlers. Môžete to vykonať manuálne pomocou AppCmd z príkazového riadku:

%SystemRoot%\system32\inetsrv\appcmd migrate config "Default Web Site/"

Použitím AppCmd pre migráciu umožníte, aby aplikácia pracovala v Integrated mode a taktiež v Classic mode alebo predchádzajúcich verziách IIS. Ak ste presvedčení, že je to v poriadku, ignorujte túto chybu a môžete ju vypnúť pomocou nastavenia system.webserver/validation@validateIntegratedModeConfiguration na hodnotu false.

<system.webServer>    
    <validation validateIntegratedModeConfiguration="false" />
</system.webServer>

2) Možete migrovať aplikáciu manuálne pomocou presunutia jednotlivých častí z <system.web>/<httpModules> a <system.web>/<httpHandlers> do <system.webServer>/<handlers> a <system.webServer>/<modules> alebo vypnutím chyby pomocou nastavenia system.webserver/validation@validateIntegratedModeConfiguration na hodnotu false.

<system.webServer>    
    <validation validateIntegratedModeConfiguration="false" />
</system.webServer>

3) Ďalšou možnosťou je prepnúť aplikáciu do Classic mode. Túto možnosť použite len v prípade, že nie je možné migrovať aplikáciu do Integrated mode.

%SystemRoot%\system32\inetsrv\appcmd set app "Default Web Site/" /applicationPool:"Classic .NET AppPool"

2) ASP.NET aplikácia hlási upozornenie, keď aplikácia obsahuje v konfigurácií zapnutie impersonácie pomocou <identity impersonate="true"> 

HTTP Error 500.24 - Internal Server Error

An ASP.NET setting has been detected that does not apply in Integrated managed pipeline mode.

Module: ConfigurationValidationModule
Notification: BeginRequest
Handler: StaticFile
Error Code: 0x80070032

Most likely causes:

system.web/identity@impersonate is set to true.

Things you can try:

  • If the application supports it, disable client impersonation. If you are certain that it is OK to ignore this error, it can be disabled by setting system.webServer/validation@validateIntegratedModeConfiguration to false.
  • Move this application to an application pool using Classic .NET mode - for example, %SystemRoot%\system32\inetsrv\appcmd set app "Default Web Site/" /applicationPool:"Classic .NET AppPool" 

Chyba nastáva, pretože ASP.NET Integrated mode nedokáže impersonovať požiadavok identity v časti BeginRequest a AuthenticateRequest pipeline.

Riešenie:

1) Pokiaľ sa aplikácia nespolieha na impersonáciu žiadajúceho užívateľa v BeginRequest a AuthenticateRequest časti (časti, kde nie je možné využívať impersonáciu v Integrated mode), ignorujte chybu následujúcim nastavením aplikácie vo web.config:

<system.webServer>    
    <validation validateIntegratedModeConfiguration="false" />
</system.webServer>

2) Pokiaľ sa aplikácia spolieha na impersonáciu žiadajucého užívateľa v BeginRequest a AuthenticateRequest časti (časti, kde nie je možné využívať impersonáciu v Integrated mode), alebo nie ste si tým istý, presuňte aplikáciu do Classic mode.

3) Dostanete chybu, keď aplikácia obsahuje v konfigurácií zakryptovanú sekciu <identity> 

HTTP Error 500.19 - Internal Server Error

The requested page cannot be accessed because the related configuration data for the page is invalid.

Configuration section encryption is not supported.

Chyba nastáva, keď sa IIS pokúša validovať sekciu <identity> a nedokáže ju dekryptovať.

Riešenie:

1) Pokiaľ aplikácia nemá problem s impersonovaním z bodu #2, migrujte aplikáciou použitím AppCmd podobne ako v bode #1:

%SystemRoot%\system32\inetsrv\appcmd migrate config "Default Web Site/"

Toto zabezpečí, že zvyšok konfigurácie aplikácie bude premigrovaný a následne pridáme do web.config ignorovanie sekcie <identity>:

<system.webServer>    
    <validation validateIntegratedModeConfiguration="false" />
</system.webServer>

2) Pokiaľ ma stále aplikácia  problém s impersonáciou, presuňte aplikáciu do Classic mode.

Autentikácia, autorizácia a impersonácia

V Integrated mode, IIS aj ASP.NET boli zjednotené. Z toho dôvodu IIS autentikácia nie je dostupná počas požiadavky PostAuthenticateRequest, keď ASP.NET aj IIS autentikácia bola dokončená.

To spôsobuje následujúce zmeny:

4) Aplikácie nemôžu súčasne používať FormsAuthentication a WindowsAuthentication

Narozdiel od Classic mode, nie je možné používať Forms Authentication v ASP.NET a stále požadovať užívateľa autentikovať sa pomocou metódy Windows Authentication, Basic Authentication, atď.

Pokiaľ je zapnutá Forms Authentication, všetky ostatné autentikačné metódy s výnimkou Anonymous Authentication by mali byť vypnuté.

Ďalej, keď používame Forms Authentication, prejavia sa následujúce zmeny:

  • Serverová premenná LOGON_USER bude nastavené na meno užívateľa prihlaseného pomocou Forms Authentication.
  • Nebude možné impersonovať autentikovaného klienta. K impersonovaniu klienta sa musí použiť autentikačná metóda, ktorá využíva Windows užívateľa narozdiel od Forms Authentication.

Riešenie:

1) Pridajte aplikácií podporu pomocou modelu vysvetleného v článku Implementing a two level authentication scheme s použitím Forms Authentication a inej IIS autentikačnej metódy v IIS 7.0.

5) Windows Authentication je štandardne vykonávaná v kerneli. To môže spôsobiť HTTP klientom, že odoslané prihlasovanie údaje spôsobia chybu počas inicializačnej požiadavky

Kernel-mode autentikácia je štandardne zapnutá v IIS 7.0. To zlepšuje výkonnosť Windows Authentication a zjednodušuje nasadenie autentikačného protokoju Kerberos. Avšak to môže spôsobiť niektorým klientom, že počas odosielania prihlasovacích údajov windows credentials na inicializačnej požiadavke nastane chyba z dôvodu navrhnutých obmedzení v kernel-mode autentikácií.Normálne prehliadače nie sú ovplyvnené, pretože oni vždy odosielajú inicializačnú požiadavku anonymne.

Pozn.: Táto zmena platí pre obidva Classic mode aj Integrated mode.

Riešenie:

1) Zakážte kernel-mode autentikáciu nastavením userKernelMode na "false" v sekcii system.webServer/security/authentication/windowsAuthentication.To môžete vykonať pomocou AppCmd následovne:

%windir%\system32\inetsrv\appcmd set config /section:windowsAuthentication /useKernelMode:false

6)  Passport autentikácia nie je podporovaná

HTTP Error 500 - Server Error

The PassportManager object could not be initialized. Please ensure that Microsoft Passport is correctly installed on the server.

Passport autentikácia nie je ďalej podporovaná vo Windows Vista a Windows Server 2008.

Pozn.: Táto zmena platí pre obidva Classic mode aj Integrated mode.

7) HttpRequest.LogonUserIdentity vyvoláva výnimku InvalidOperationException, keď je volaný v module pred požiadavkom PostAuthenticateRequest

HTTP Error 500 - Server Error

This method can only be called after the authentication event.

HttpRequest.LogonUserIdentity vyvoláva výnimku InvalidOperationException, keď je volaný v module pred požiadavkom PostAuthenticateRequest, pretože hodnota tejto vlastnosti je neznáma predtým ako je klient autentikovaný.

Riešenie:

1) Zmeniť kód tak, aby nepoužival HttpRequest.LogonUserIdentity skôr ako je spracovaná požiadavka PostAuthenticateRequest.

8) Impersonácia klienta nie je použitá v module v časti BeginRequest and AuthenticateRequest.

Autentikovaný užívateľ nie je známy počas PostAuthenticateRequest. Preto ASP.NET neimpersonuje autentikovaných užívateľov v ASP.NET moduloch, ktoré bežia počas požiadavky BeginRequest a  AuthenticateRequest. To može postihnúť vašu aplikáciu, pokiaľ máte nejaký modul, ktorý sa spolieha na impersonáciu užívateľa pre validáciu prístupu alebo pristupovaniu k zdrojom v týchto požiadavkách.

Riešenie:

1) Zmeňte vašu aplikáciu tak, aby nevyžadovala impersonáviu klienta počas BeginRequest a  AuthenticateRequest.

9) Definovanie metódy DefaultAuthentication_OnAuthenticate v global.asax vyvoláva výnimku PlatformNotSupportedException

HTTP Error 500 - Server Error

The DefaultAuthentication.Authenticate method is not supported by IIS integrated pipeline mode.

V Integrated mode nie je udalosť DefaultAuthenticationModule.Authenticate implementovaná a preto nie je naďalej volaná. V Classic mode sa táto udalosť volá, keď nenastala autentikácia.

Riešenie:

1) Zmeňte aplikáciu tak, aby nevyžadovala udalosť DefaultAuthentication_OnAuthenticate. Namiesto toho, napíšte IHttpModule, ktorý kontroluje či HttpContext.User je null z dôvodu zistenia, či je užívateľ autentikovaný.

10) Aplikácia, v ktorej sa používa udalosť WindowsAuthentication_OnAuthenticate v global.asax nie je volaná, keď je požiadavka anonymná

Pokiaľ definujete metódu WindowsAuthentication_OnAuthenticate v global.asax, nebude vyvolaná pre anonymné požiadavky. To je z toho dôvodu, pretože sa anonymná autentikácia vyskytuje potom, ako modul WindowsAuthentication môže zavolať udalosť OnAuthenticate.

Riešenie:

Zmeňte aplikáciu tak, aby nevyžadovala udalosť WindowsAuthentication_OnAuthenticate. Namiesto toho, napíšte IHttpModule, ktorý beží v PostAuthenticateRequest a kontroluje či HttpContext.User je null z dôvodu zistenia, či je užívateľ autentikovaný.

Žiadost obmedzuje spracovanie URL

Následujúce zmeny vyplývajú z pridaných obmedzeni na spracovaní IIS prichádzajúcich požiadaviek a ich URL.

11) Požiadavka, ktorej URL obsahuje nekodovaný znak '+' v ceste (nie QueryString) je štandardne zamietnutá.

HTTP Error 404.11 - Not Found

The request filtering module is configured to deny a request that contains a double escape sequence.

Táto chyba vzniká z dôvodu, pretože štandardné nastavenie blokuje pokusy pre dvojito kódované URL, ktoré zvyčajne predstavujú pokus o vyvolanie kanonického útoku.

Riešenie:

1) Pre aplikáciu, ktorá vyžaduje znak '+' v URL, môžete vypnúť validáciu nastavením atribútu allowDoubleEscaping na hodnotu v sekcii system.webServer/security/requestFiltering vo web.config. Avšak to môže spôsobiť, že vaša aplikácia môže byť napadnutá zlomyseľnými URL.

<system.webServer>   
    <security>       
        <requestFiltering allowDoubleEscaping="true" />   
    </security>
</system.webServer>

12) Požiadavky s QueryString dlhším ako 2048 bajtov sú štandardne zamietnuté

HTTP Error 404.15 - Not Found

The request filtering module is configured to deny a request where the query string is too long.

IIS štandardne zamieta QueryString dlhši ako 2048 bajtov. To môže mať dopad na vašu aplikáciu, keď používate dlhé QueryStrings alebo cookieless možnosti ASP.NET ako Forms Authentication albo iné, ktoré kumulovane presahujú nastavený limit pre QueryString.

Pozn.: Táto zmena platí pre obidva Classic mode aj Integrated mode.

Riešenie:

1) Zvýšenie limitu maximálne dĺžky QueryString nastavením atribútu maxQueryString v elemente requestLimits v sekcii system.webServer/security/requestFiltering vo web.config.

<system.webServer>   
    <security>       
        <requestFiltering>           
            <requestLimits maxQueryString="NEW_VALUE_IN_BYTES" />        
        </requestFiltering>    
    </security>
</system.webServer>

Zmeny v spracovaní hlavičky odozvy (response header)

Tieto zmeny ovplyvňujú ako sú hlavičky odozvy generované aplikáciou.

13) IIS vždy zamieta nové riadky v hlavičkach odozvy (aj keď je enableHeaderChecking je nastavené na "false")

HTTP Error 500 - Server Error

Value does not fall within the expected range.

Táto chyba nastáva, pokiaľ vaša aplikácia tvorí hlavičky s prázdnymi riadkami (akákoľvek kombinácia \r alebo \n)

IIS bude zamietať akýkoľvek pokus k vyvolaniu odozvy hlavičiek s prázdnymi riadkami, aj keď je enableHeaderChecking vypnuté. To je z dôvodu ochrany hlavičiek pred útokymi, ktoré spájaju hlavičky (splitting attacks)

Pozn.: Táto zmena platí pre obidva Classic mode aj Integrated mode.

14) Keď je odozva (response) prázdna, hlavička Content-Type nie je potlačená

Pokiaľ aplikácia nastavuje v hlavičke Content-Type, tak zostane uvedená, aj keď je odozva prázdna. Požiadavky na typ obsahu ASP.NET bude štandardne obsahovať "Content-Type: text/html" v odozvách, jedine že by boli prepísané aplikáciou.

Riešenie:

1) Pokiaľ by toto malo prelomový efekt v aplikácií, možete Content-Type hlavičku nastaviť explicitne pomocou vlastnosti HttpResponse.ContentType na null, keď je odozva prázdna.

15) Pokiaľ sú hlavičky odozvy vyčitené pomocou HttpResponse.ClearHeaders, štandardné ASP.NET hlavičky nie sú generované. To može mať za následok nedostatok v Cache-Control: private hlavička ktorá bráni cachovaniu odozvy na klientskej strane

HttpResponse.ClearHeaders štandardne neregenerujú ASP.NET odozvy hlavičiek, vrátane “Content-Type: text/html” a “Cache-Control: private”, tak ako to bolo v Classic mode. To je z dôvodu, že ASP.NET moduly môžu volať API so žiadosťou o akykoľvek typ zdroja, a tak generovanie špecifických ASP.NET hlavičiek nie je vhodné. Nedostatok “Cache-Control” hlavičky môže prinútiť niektoré downstream sieťové zariadenia ku cachovaniu odozvy.

Riešenie:

1) Zmeňte v aplikácií manuálne generovanie Cache-Control: private keď hlavička vyčistí odozvu, pokiaľ bude požadované zabrániť cachovaniu v downstream sieťových zariadeniach.

Zmeny v aplikáciách a moduloch pre spracovanie udalostí

Tieto zmeny môžu ovplyvniť

These changes affect how the application and module event processing takes place.

16) It is not possible to access the request through the HttpContext.Current property in Application_Start in global.asax

HTTP Error 500 - Server Error

Request is not available in this context.

Táto chyba nastáva, pokiaľ vaša aplikácia pristupuje k aktuálnemu obsahu požiadavky (request context) v metóde Application_Start  v global.asax ako časť inicializácie.

Chyba je spôsobená, pretože inicializácia ASP.NET aplikácie ma odpojnené väzby zo žiadostí, ktoré ich spúšťajú. V Classic mode bolo možné pristupovať nepriamo k obsahu požiadavky pomocou vlastnosti HttpContext.Current. V Integrated mode tento obsah nereprezentuje aktuálnu požiadavku a tak pokusy k prístupu na objekty Request a Reponse vyvolajú výnimku. 

Riešenie:

1) Pozri či nie je dostupný Request v Application_Start pre detailný popis výnimky a na základe toho aplikáciu opraviť.

17) Poradie, v ktorom spúšťajú moduly event handlers, môže byť rozdielne ako je Classic mode

Existujú následujúce rozdiely:

  • Pre každú udalosť, event handers pre každý modul sú spúštané v takom poradí, v akom sú konfigurované v  sekcii <modules>. Global.asax event handlers sú spúšťané potom.
  • Moduly, ktoré sa registrujú pre PreSendRequestHeaders a PreSendRequestContent udalosti sú informované v opačnom poradí ako sú uvedené v sekcii <modules>.
  • Pre každú udalosť, súčasne event handers pre každý modul sú spúštané pred asynchrónnymi handlermi. Inak, event handlers, sú spúštané v takom poradí, v akom sú registrované.

Aplikácie, ktoré majú niekoľko konfigurovaných modulov bežiacich v ktorejkoľvek z týchto udalostí možu byť ovplyvnené touto zmenou pokiaľ závisia na poradí udalostí. To je málo pravdepodobné pre väčšinu aplikácií. Poradie, v ktorom sú moduly spúšťané môžu byť získane z Failed Request Tracing logu.

Riešenie:

1) Zmeňte poradie modulov podľa toho ako na sebe závisia v sekcii  system.webServer/modules vo web.config.

18) ASP.NET moduly v dobe skorého spracovania požiadavky uvidia požiadavky, ktoré môžu byť zamietnuté na IIS pred spustením. To zahŕňa moduly bežiace v BeginRequest vidiace anonymné požiadavky pre zdroje, ktoré vyžadujú autentikáciu

ASP.NET moduly môžu bežat v akejkoľvek pipeline, ktorá je dostupná pre IIS moduly. Kvôli tomu, požiadavky ktoré môžu byť zamietnuté v stave autentikácie (napr. anonymné požiadavky pre zdroje, ktoré vyžadujú autentikáciu), alebo iné stavy pre spustením ASP.NET, možu bežat ASP.NET moduly. Toto správanie je navrhnuté za účelom povolenia ASP.NET modulov rozšíriť IIS vo všetkych možných stavoch spracovania požiadavky.

Riešenie:

1) Zmeňte kód aplikácie k vyvarovaniu sa akýchkoľvek špecifických problémov, ktoré môžu vniknúť tým, že vidia požiadavky, ktoré môžu byť zamietnuté počas ich spracovania. To môže zahŕňať zmenu modulov pri zapísaní sa do pipeline udalostí, ktoré sú vyvolané počas ďalšieho spracovania požiadaviek.

Ďalšie zmeny v aplikáciách

Ďalšie zmeny, ktoré môžu vzniknúť v ASP.NET aplikáciách a API.

19) DefaultHttpHandler nie je podporovaný. Aplikácié založené na triedach DefaultHttpHandler nebudú mocť spracovať požiadavky.

Pokiaľ vaša aplikácia používa DefaultHttpHandler alebo handlers pochádzjúce z DefaultHttpHandler, nebudú pracovať korektne. V Integrated mode, handlers pochádzjúce z DefaultHttpHandler, nebudú schopné prejsť požiadavkom späť k IIS na spracovanie a miesto toho slúži požadovaný zdroj ako statický súbor. Integrated mode dovoľuje ASP.NET modulom spúšťať všetky požiadavky bez vyžadovania použitia DefaultHttpHandler.

Riešenie:

1) Zmeňte vašu aplikáciu tak, aby mohla využívať moduly k vykonaniu všetkých požiadaviek, namiesto použitia wildcard mapping k mapovaniu ASP.NET pre všetky požiadavky a potom použiť handlers pochádzjúce z DefaultHttpHandler na prejdenie požiadavky spať k IIS.

20) Je možné písať do odozvy aj keď nastava výnimka

V Integrated mode je možné písať a zobrazovať dodatočne odozvy po vyvolaní výnimky. Typicky v moduloch, ktoré odoberajú LogRequest a EndRequest udalosti. Toto nenastáva v Classic mode. Keď chyba nastane počas spracovania požiadavky a aplikácia zapíše do odozvy v EndRequest po vyvolaní výnimky, odozva zapísaná v EndRequest bude zobrazená. To ovplyvní požiadavky, ktoré majú neodchytené výnimky.

Riešenie:

1) K vyvarovaniu sa zapisovaniu do odozvy po vyvolani vynimky, aplikácia môže skontrolovať HttpContext.Error alebo HttpResponse.StatusCode pred zapísaním do odozvy.

21)  Nie je možné používať ClearError API k zabráneniu výnimky pred zapísaním do odozvy, keď bola výnimka vyvolaná v predchádzajúcom stave pipeline

Volanie Server.ClearError počas EndRequest udalosti nevčistí výnimku, pokiaľ bola vyvolaná v predchádzajúcej udalosti v pipeline. To je pretože výnimka je formátovaná k odozve na konci každej udalosti, keď vyzdvihne výnimku.

Riešenie:

1) Zmeňte vašu aplikáciu na volanie Server.ClearError z Application_OnError event handler, ktorý vyzdviháva kedykoľvek výnimku, ktorá vola vyvolaná.

22) HttpResponse.AppendToLog nerobí automaticky pridávanie QueryString do URL

Keď používame HttpResponse.AppendToLog k pridávaniu vlastného reťazca do URL logovaného v požadovanom logovacom súbore, musíme manuálne pridať QueryString do reťazca vkladaného do tohto API. To sa môže prejaviť v existujúcom kóde statou QueryString z logov URL, keď je toto API použité.

Riešenie:

1) Zmeňte vašu aplikáciu na manuálne pridávanie HttpResponse.QueryString.ToString() vo reťazca vkladaného do HttpResponse.AppendToLog.

Ďalšie zmeny

23) ASP.NET nastavenia threading nie sú použité pri riadení súčinnosti požiadaviek v Integrated mode

Nastavenia minFreeThreads, minLocalRequestFreeThreads v sekcii system.web/httpRuntime a maxWorkerThreads  v sekcii processModel naďalej neriadia mechanizmus vlákien používaných v ASP.NET. Namiesto toho, ASP.NET sa spolieha na IIS thread pool a dovoľuje ovládať maximálny počet súbežne vykonávaných žiadostí pomocou nastavenia hodnoty MaxConcurrentRequestsPerCPU DWORD (štandardne je 12) v registroch klúča HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\2.0.50727.0. Toto nastavenie je globálne a nemôže byť menené individuálne v aplikačných pooloch alebo aplikáciach.

Riešenie:

1) Pre riadenie konkurencie vašej aplikácie, nastavte MaxConcurrentRequestsPerCPU.

24) ASP.NET aplikáčné rady nie sú použité v Integrated mode. Preto "ASP.NET Applications\Requests in Application Queue" performance counter bude mať vzdy hodnotu 0.

ASP.NET nepoužíva aplikačné rady v Integrated mode.

25) IIS 7.0 vždy reštartuje ASP.NET aplikácie, keď bola vykonaná zmena vo web.configu root aplikácie. Z tohto dôvodu waitChangeNotification a maxWaitChangeNotification atribúty nemajú žiadny efekt

IIS 7.0 monitoruje zmeny web.config súborov a to je dôvod prečo ASP.NET aplikácie korešpodujú k tomuto súboru pri reštarte bez ohľadu na ASP.NET nastavenia notifikácie zmien vrátane waitChangeNotification a maxWaitChangeNotification atribútov v sekcii system.web/httpRuntime.


Milan Pašek, MCPD

Som zakladateľom spoločnosti Quantasoft, s.r.o., zakladateľom prvého freehostingu pre ASP.NET na Slovensku (Quantasoft Web Hosting) a podporovateľom komunitných aktivít v rámci možností. Z veľkej časti sa zaoberám vývojom software a návrhom informačných systémov na zákazku.

Článkov: 5, Správičiek: 0, Príspevkov vo fóre: 21, Príspevkov v blogu: 9, Bodov: 855
Najaktívnejší č.: 25
Profil používateľa

Reakcie

Pridať reakciu

Titulok:
Meno:
Url:
Koľko je 22 + 4?
(ochrana proti spamu)
Komentár:

Najaktívnejší užívatelia
1. 37770 b. photo vlko
2. 21430 b. photo T
3. 15955 b. photo spigi
4. 15450 b. photo Anonymous
5. 11120 b. photo dudok
6. 9610 b. photo Liero
7. 6910 b. photo siro
8. 6245 b. photo slavof
9. 5395 b. photo duracellko
10. 4620 b. photo xxxmatko