Problema con Config Group quando si aggiorna a .NET 4.0

Question

Quindi abbiamo aggiornato il nostro sito da 3,5 SP1 -> .NET 4.

Quando abbiamo corso il sito, abbiamo ottenuto un errore interno del server (500), affermando che non è stato possibile leggere il seguente gruppo di configurazione:

<system.web.extensions>
        <scripting>
            <scriptResourceHandler enableCompression="true" enableCaching="true" />
            <webServices>
                <jsonSerialization maxJsonLength="999999" />
            </webServices>
        </scripting>
    </system.web.extensions>

.

Abbiamo commentato questa sezione e il sito web è andato bene (ma ora stiamo ricevendo problemi con JSON - a causa della proprietà richiesta sopra richiesta).

Abbiamo letto discussioni su questo tema, e la maggior parte di esse dire "Il pool di applicazioni non è in esecuzione 4.0". Ed è, quindi non è il problema.

Ho anche letto i thread che dicono che IIS è in qualche modo leggendo un vecchio file machine.config.

Con .NET 4, come conosci molte delle sezioni di Web.config sono state spostate su Machine.Config.

Quindi mettiamo indietro questa sezione nella parte superiore del web.config:

<sectionGroup name="system.web.extensions" type="System.Web.Configuration.SystemWebExtensionsSectionGroup, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35">
            <sectionGroup name="scripting" type="System.Web.Configuration.ScriptingSectionGroup, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35">
                <section name="scriptResourceHandler" type="System.Web.Configuration.ScriptingScriptResourceHandlerSection, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" requirePermission="false" allowDefinition="MachineToApplication"/>
                <sectionGroup name="webServices" type="System.Web.Configuration.ScriptingWebServicesSectionGroup, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35">
                    <section name="jsonSerialization" type="System.Web.Configuration.ScriptingJsonSerializationSection, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" requirePermission="false" allowDefinition="Everywhere" />
                    <section name="profileService" type="System.Web.Configuration.ScriptingProfileServiceSection, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" requirePermission="false" allowDefinition="MachineToApplication" />
                    <section name="authenticationService" type="System.Web.Configuration.ScriptingAuthenticationServiceSection, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" requirePermission="false" allowDefinition="MachineToApplication" />
                    <section name="roleService" type="System.Web.Configuration.ScriptingRoleServiceSection, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" requirePermission="false" allowDefinition="MachineToApplication" />
                </sectionGroup>
            </sectionGroup>
        </sectionGroup>

.

E il sito Web ora sembra funzionare bene.

Ancora, sono un po 'preoccupato se questa è la soluzione corretta.

Qualche idea? È questa corretta correzione?

Modifica:

3 settimane e nessuna risposta ... dannazione.=)

Answer 1

Come non ho avuto risposte, e l'ampio googling ha portato a nessun amore, ho deciso di attaccare la mia correzione originale (aggiungendo la sezione System.Web.Extensions nel Web.Config).

Answer 2

Ho corso recentemente questo problema ed è stato in grado di risolverlo dopo una risoluzione dei problemi.Spero che cosa ho aiutato anche a riparare il tuo problema. 1. Assicurati che il pool dell'app che sia in esecuzione per il sito stia utilizzando .NET 4 pipeline 2. Apri il tuo .csproj (o .vbproj se il tuo è un progetto VB) nel Blocco note e nel processore e controlla il file e verificare se ci sono riferimenti hard codificati ai file quadro V2.0.Nel mio caso abbiamo avuto un compito "After Build" che utilizzava il percorso del compilatore V2.0 che ha costretto l'app per utilizzare ancora 2,0 runtime.Era come sotto.

<Target Name=”AfterBuild” Condition=”’$(MvcBuildViews)’==’true’”>
<AspNetCompiler Condition=”’$(IsDesktopBuild)’ != ‘false’” VirtualPath=”temp” ToolPath=”$(WINDIR)\Microsoft.NET\Framework\v2.0.50727” PhysicalPath=”$(ProjectDir)\..\$(ProjectName)” />
<AspNetCompiler Condition=”’$(IsDesktopBuild)’ == ‘false’” VirtualPath=”temp” ToolPath=”$(WINDIR)\Microsoft.NET\Framework\v2.0.50727” PhysicalPath=”$(OutDir)\_PublishedWebsites\$(ProjectName)” />

.

Assicurati di cambiarli in V4.0 o anche meglio renderli confidenziali. Spero che ti aiuti.

-VAMSI

Answer 3

altri due bit di informazioni che possono o non possono aiutare.

.
1. L'unica differenza dal gruppo di sezione di cui sopra e il mio sectiongroup della macchina è la versione= 3.5.0.0 qui e versione= 4.0.0.0 nella macchina.Config. 1.
2. L'errore nel registro eventi è "Impossibile caricare tutti i filtri ISAPI per il sito ..." potrebbe esserci un'installazione di System.Web.Extensions che non è registrata correttamente con .NET 4?

Mi piacerebbe verificare più su questo, ma sfortunatamente vedo questo comportamento in un sistema di produzione e non un sistema di sviluppo.