Problema com <system.web.extensions> configuração de grupo quando actualizar para .NET 4.0

Question

Então, nós atualizamos o nosso site a partir de 3.5 SP1> .NET 4.

Quando executamos o site, temos um Erro Interno do Servidor (500), afirmando o seguinte configuração de grupo não pode ser lido:

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

Nós comentamos nesta seção e o site correu bem (mas agora estamos a ter problemas com JSON - porque o acima propriedade necessária).

Temos de ler tópicos sobre este assunto, e a maioria deles dizem que "o Seu pool de aplicativo não está em execução 4.0".E é, então esse não é o problema.

Eu também li threads dizendo que o IIS está, de alguma forma, a leitura de uma máquina antiga.arquivo de configuração.

Com .NET 4, como você sabe, um monte de secções da web.configuração foram movidos para a máquina.config.

Então nós colocamos esta seção de volta no topo do site.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 o site agora parece funcionar ok.

Ainda assim, estou um pouco preocupado se essa é a solução correta.

Quaisquer ideias de pessoas?É esta a correcção correcta?

EDITAR:

3 semanas e não há respostas...porra.=)

Answer 1

Como eu não tinha respostas, e extensa pesquisa no google resultou em amor, eu decidi meter minha correção original (adicionando o sistema.da web.seção extensões de volta para a web.config).

Answer 2

Eu tive esse problema recentemente e foi capaz de resolvê-lo depois de alguns resolução de problemas.Espero que o que eu fiz vai ajudar a corrigir o seu problema também.1.Certifique-se de que o pool de Aplicativo que você está executando para o site está usando .NET 4 pipeline 2.Abra o seu .csproj (ou .vbproj se o seu caso é um projeto do VB) no bloco de notas e instruções do arquivo e verifique se há qualquer codificado referências para v2.0 Quadro de arquivos.No meu caso, que tinha um "Depois" construção da tarefa que estava usando v2.0 compilador caminho, o que forçou o aplicativo ainda utilizar 2.0 tempo de execução.Era como abaixo.

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

Certifique-se de mudar a v4.0 ou ainda melhor, torná-los confiurable.Espero que ajude.

-Vamsi

Answer 3

Mais dois bits de informação que pode ou não pode ajudar.

1. a única diferença do acima sectionGroup e a minha máquina sectionGroup é a versão=3.5.0.0 aqui e version=4.0.0.0 na máquina.config.1.
2. O erro no log de eventos é "não Pode carregar todos os filtros ISAPI para o site..." Poderia haver uma instalação do Sistema.Da Web.Extensões que não está registrado corretamente com .net 4?

Eu adoraria testar mais sobre isso, mas infelizmente só vejo esse comportamento em um sistema de produção e não um dev do sistema.