Problème avec Groupe de configuration lors de la mise à niveau vers .NET 4.0

Question

Nous avons donc mis à niveau notre site de 3.5 SP1 -> .NET 4.

Lorsque nous avons dirigé le site, nous avons eu une erreur de serveur interne (500), indiquant que le groupe de configuration suivant n'a pas pu être lu:

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

Nous avons commenté cette section et le site Web a fonctionné bien (mais nous rencontrons maintenant des problèmes avec JSON - en raison de la propriété requise ci-dessus).

Nous avons lu des threads sur ce numéro et la plupart d'entre eux disent "Votre pool d'applications ne fonctionne pas 4.0". Et c'est donc ce n'est pas le problème.

J'ai aussi lu des discussions disant que IIS est en quelque sorte en train de lire un ancien fichier machine.config.

avec .NET 4, comme vous savez que beaucoup de sections de web.config ont été déplacées à la machine.config.

Nous remettons cette section dans le haut de la page 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>

Et le site Web semble maintenant fonctionner correctement.

toujours, je suis un peu inquiet s'il s'agit de la solution correcte.

Des idées de personnes? Est-ce le correctif correct?

EDIT:

3 semaines et pas de réponses ... putain.=)

Answer 1

Comme je n'ai pas eu de réponses et que de vastes googles ont entraîné une amour sans amour non plus, j'ai décidé de coller mon correctif d'origine (ajouter la section System.Web.extensions dans le Web.config).

Answer 2

J'ai récemment couru dans ce problème et a été capable de le résoudre après un dépannage.J'espère que ce que j'ai fait aidera à résoudre votre problème aussi. 1. Assurez-vous que le pool d'applications que vous utilisez pour le site utilise .NET 4 Pipeline 2. Ouvrez votre fichier .csproj (ou .vbproj si le vôtre est un projet VB) dans le bloc-notes et parcayez le fichier et vérifiez s'il y a des références codées durs aux fichiers-cadres V2.0.Dans mon cas, nous avons eu une tâche "après la construction" utilisant le chemin de compilateur V2.0 qui a forcé l'application pour toujours utiliser 2.0 Runtime.C'était comme ci-dessous.

<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)” />

Assurez-vous de les changer en v4.0 ou même mieux les rendre confiables. Espère que cela aide.

-vamsi

Answer 3

Deux autres bits d'informations qui peuvent ou non aider.

1. La seule différence entre le groupe SECTION SECTION ci-dessus et ma sectionGROUP est la version= 3.5.0.0 ici et la version= 4.0.0.0 dans la machine.config. 1.
2. L'erreur dans le journal des événements est "Impossible de charger tous les filtres ISAPI pour le site ..." pourrait-il y avoir une installation de system.web.extensions qui ne sont pas enregistrées correctement avec .NET 4?

J'adorerais tester plus sur cela, mais malheureusement, je ne vois malheureusement que ce comportement dans un système de production et non un système DEV.