Para exibir a versão mais recente do Leiame, clique aqui.
Esse problema pode ser causado pelos seguintes cenários:
O texto completo do erro é o seguinte:
Não foi possível carregar o tipo 'System.ServiceModel.Activation.HttpModule' do assembly 'System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'.
Descrição: ocorreu uma exceção sem tratamento durante a execução da solicitação da Web atual. Examine o rastreamento de pilha para obter mais informações sobre o erro e onde ele se originou no código.
Para resolver esse problema:
Em um computador com o IIS 7 ou o IIS 7.5 habilitado e o .NET Framework 4 instalado, a desinstalação da versão Beta 2 deixa entradas "isapiCgiRestriction" não utilizadas no arquivo applicationHost.config. Isso ocorre no Windows Vista, no Windows Server 2008 e no Windows 7. As entradas não utilizadas não afetam a funcionalidade do servidor Web. As versões posteriores do .NET Framework 4 podem ser instaladas com segurança no mesmo computador, pois as atualizações subsequentes atualizarão as entradas "isapiCgiRestriction".
Para resolver esse problema:
Exclua as entradas "isapiCgiRestriction" não utilizadas do arquivo applicationHost.config. Porém, esta etapa não é obrigatória, pois as entradas deixadas após a desinstalação não afetam a funcionalidade do produto nem a capacidade de instalar versões posteriores.
O .NET Framework 1.0 não pode ser instalado após a instalação do .NET Framework 4. O .NET Framework 1.0 deve ser instalado antes da instalação do .NET Framework 4.
Para resolver esse problema:
A Instalação do .NET Framework 4 falhou.
Para resolver esse problema:
Consulte o guia de solução de problemas da Instalação do .NET Framework 4 (http://go.microsoft.com/fwlink/?LinkId=186690)
O Serviço de Cache de Fontes do Windows Presentation Foundation (WPF) 4 não é totalmente removido depois que o .NET Framework 4 é desinstalado (.NET Framework Full).
Observação: esse problema afeta as versões Full e Client Profile do .NET Framework.
Para resolver esse problema:
“[SC] DeleteService SUCCESS” deverá ser exibido.
Quando você atualizar o console de serviços, o Cache de Fontes deverá aparecer. Se essa atualização não corrigir o problema, reinicie o computador.
O .NET Framework 1.0 não pode ser instalado após a instalação do .NET Framework 4 Client Profile. O .NET Framework 1.0 deve ser instalado antes da instalação do .NET Framework 4 Client Profile.
Para resolver esse problema:
Quando o .NET Framework 4 é desinstalado, o serviço Cache de Fontes do WPF pode não ser totalmente desinstalado.
Embora o serviço Cache de Fontes do WPF não seja mais utilizável após a desinstalação, a entrada de serviços do “Windows Presentation Foundation Font Cache 4.0.0.0” ainda é exibida no console Serviços.
No Windows Vista e no Windows Server 2008, o campo “Descrição” do console de serviços informará: “<Falha ao Ler Descrição. Código de Erro: 2 >”. No Windows XP e no Windows Server 2003, o campo “Descrição” ainda exibirá a cadeia de caracteres correta.
A reinstalação do .NET Framework reparará isso. Nenhum outro efeito é conhecido.
Observação: esse problema afeta as versões Full e Client Profile do .NET Framework.
Para resolver esse problema:
“[SC] DeleteService SUCCESS” deverá ser exibido.
Quando você atualizar o console de serviços, o Cache de Fontes deverá aparecer. Se essa atualização não corrigir o problema, reinicie o computador.
A Instalação do .NET Framework 4 Client Profile falhou.
Para resolver esse problema:
Consulte o guia de solução de problemas da Instalação do .NET Framework 4 (http://go.microsoft.com/fwlink/?LinkId=186690)
Em um computador com o IIS 7 ou o IIS 7.5 habilitado e o .NET Framework 4 instalado, a desinstalação da versão Beta 2 deixa entradas "isapiCgiRestriction" não utilizadas no arquivo applicationHost.config. Isso ocorre no Windows Vista, no Windows Server 2008 e no Windows 7. As entradas não utilizadas não afetam a funcionalidade do servidor Web. As versões posteriores do .NET Framework 4 podem ser instaladas com segurança no mesmo computador, pois as atualizações subsequentes atualizarão as entradas "isapiCgiRestriction".
Para resolver esse problema:
Exclua as entradas "isapiCgiRestriction" não utilizadas do arquivo applicationHost.config. Porém, esta etapa não é obrigatória, pois as entradas deixadas após a desinstalação não afetam a funcionalidade do produto nem a capacidade de instalar versões posteriores.
A solução para remover totalmente esse serviço de Cache de Fontes órfão é a seguinte:
Você deverá ver: “[SC] DeleteService SUCCESS”.
Se você atualizar o console de serviços, o Cache de Fontes não deverá aparecer agora. Talvez seja necessário reinicializar o computador se a atualização do console de serviços não corrigir o problema.
(Observação: esse problema corresponde ao .NET Framework Full e é uma cópia do problema 877240 do Leiame referente ao Client Profile)
Para resolver esse problema:
A solução para remover totalmente esse serviço de Cache de Fontes órfão é a seguinte:
Você deverá ver: “[SC] DeleteService SUCCESS”.
Se você atualizar o console de serviços, o Cache de Fontes não deverá aparecer agora. Talvez seja necessário reinicializar o computador se a atualização do console de serviços não corrigir o problema.
Quando o .NET Framework 4 é desinstalado do sistema operacional Vista/XP/w2k3/W2k8, o serviço de Cache de Fontes do WPF não é totalmente desinstalado.
Embora o serviço de Cache de Fontes do WPF não seja mais utilizável após a desinstalação, a entrada de serviços do “Windows Presentation Foundation Font Cache 4.0.0.0” ainda permanece visível no console Serviços.
No Windows Vista e no Windows Server 2008, o campo “Descrição” do console de serviços informará: “<Falha ao Ler Descrição. Código de Erro: 2 >”. No Windows XP/Windows Server 2003, o campo “Descrição” ainda exibirá a cadeia de caracteres correta.
A reinstalação do .NET Framework reparará isso. Nenhum outro efeito é conhecido.
Observação: esse problema se refere tanto ao Net4 Client Profile quanto ao NET4 Full
Para resolver esse problema:
A solução para remover totalmente esse serviço de Cache de Fontes órfão é a seguinte:
Você deverá ver: “[SC] DeleteService SUCCESS”.
Se você atualizar o console de serviços, o Cache de Fontes não deverá aparecer agora. Talvez seja necessário reinicializar o computador se a atualização do console de serviços não corrigir o problema.
(Observação: esse problema se refere ao Client Profile e é uma cópia do problema 888322 do Leiame referente à versão Full)
Você poderá ver um erro de compilação se estiver usando as versões do Visual Studio 2010 em chinês simplificado ou chinês tradicional para publicar um aplicativo, caso selecione a opção ‘Baixar pré-requisitos do mesmo local de meu aplicativo' na caixa de diálogo Pré-requisitos e selecione qualquer um dos seguintes componentes como pré-requisitos:
Este é o erro de compilação que você poderá ver para o ‘Microsoft .NET Framework 4 Client Profile (x86 e x64)’:
'MSB3152: O local de instalação dos pré-requisitos não foi definido como o 'site do fornecedor de componentes', e o arquivo 'DotNetFX40Client\dotNetFx40LP_Client_x86_x64cs.exe' no item 'Microsoft .NET Framework 4 Client Profile (x86 e x64)' não pode ser localizado no disco. Consulte a Ajuda para obter mais informações.
Para contornar esse problema:
Para contornar esse problema em chinês simplificado, siga estas etapas:
<String Name=”Culture”>zh-chs</String>
Para contornar esse problema em chinês tradicional, siga estas etapas:
<String Name=”Culture”>zh-cht</String>
Você talvez não consiga instalar os pacotes de idiomas chinês simplificado ou chinês tradicional se estiver usando as versões do Visual Studio 2010 em chinês simplificado ou chinês tradicional para publicar um aplicativo, caso selecione a opção ‘Baixar pré-requisitos do site do fornecedor do componente' na caixa de diálogo Pré-requisitos e selecione qualquer um dos seguintes componentes como pré-requisitos:
Para contornar esse problema:
Para contornar esse problema em chinês simplificado, siga estas etapas:
<String Name=”Culture”>zh-chs</String>
Para contornar esse problema em chinês tradicional, siga estas etapas:
<String Name=”Culture”>zh-cht</String>
Após a instalação do .NET Framework 4 em um computador cliente ou servidor que esteja executando o Windows 7 e tenha o IIS 7.5 habilitado, a opção de configurar arquivos de configuração do ASP.NET para diferentes pools de aplicativos para de funcionar. Isso ocorre porque a instalação do .NET Framework 4 causa uma ligeira alteração no comportamento padrão da inicialização do CLR (common language runtime). Quando o .NET Framework 4 é instalado, o IIS 7.5 no Windows 7 chama uma DLL nativa do ASP.NET 4 para executar a inicialização do CLR, e essa lógica de inicialização não permite o uso de diferentes arquivos de configuração.
Para resolver esse problema:
Como a lógica de inicialização do CLR é basicamente igual para o .NET Framework 4 e para o IIS 7.5 (exceto para o efeito colateral do arquivo de configuração), você pode reconfigurar o IIS 7.5 de forma que ele não delegue mais a inicialização do CLR ao ASP.NET 4. Isso pode ser feito de duas maneiras.
Opção 1
----------
No arquivo applicationHost.config do IIS 7.5, defina o valor padrão do atributo "managedRuntimeLoader" como uma cadeia de caracteres vazia, como no exemplo a seguir:
<applicationPools>
<applicationPoolDefaults managedRuntimeLoader="" />
</applicationPools>
Opção 2
----------
No arquivo IIS_Schema.xml do IIS 7.5, defina "defaultValue" no atributo denominado "managedRuntimeLoader" como uma cadeia de caracteres vazia. Por exemplo, o atributo poderá originalmente ser semelhante ao seguinte exemplo:
<attribute name="managedRuntimeLoader" type="string" defaultValue="webengine4.dll" />
Altere-o para a seguinte marcação:
<attribute name="managedRuntimeLoader" type="string" defaultValue="" />
No Windows XP e no Windows Server 2003 (todas as versões), se você cancelar o registro do ASP.NET 4 no IIS e depois registrá-lo novamente, o MMC IIS exibirá um valor vazio para a lista de versões do ASP.NET na guia ASP.NET. A sequência de etapas a seguir causará o problema:
Para resolver esse problema:
Na lista de versões do ASP.NET no MMC do IIS, selecione manualmente a versão desejada do ASP.NET e clique no botão "Aplicar".
Algumas tarefas de compilação do ASP.NET no Windows Vista, no Windows Server 2008 e no Windows 7 podem falhar porque o processo de trabalho do IIS não tem permissões para o diretório temporário Windows (%WINDOWS%\Temp). Quando você tentar compilar itens como referências a serviços Web que dependem de arquivos WSDL, poderá ver erros como este: "Mensagem de Erro do Analisador: não é possível gerar uma classe temporária".
Esse erro ocorrerá se o IIS estiver habilitado no computador e o .NET Framework 4 estiver instalado, mas os recursos ASP.NET e Extensibilidade .NET não estiverem habilitados.
Para resolver esse problema:
Opção 1
----------
Conceda explicitamente permissões de gravação ao diretório temporário Windows (%WINDOWS%\Temp) para a conta do processo de trabalho do IIS. Um modo de fazer isso é conceder acesso de gravação a um grupo que inclua a conta do processo de trabalho, por exemplo, o grupo IIS_IUSRS.
Opção 2
---------
Habilite os recursos ASP.NET e Extensibilidade .NET. No Painel de Controle do Windows, abra "Programas" e, em "Programas e Recursos", clique em "Ativar ou desativar recursos do Windows". Na caixa de diálogo "Recursos do Windows", abra o nó "Serviços de Informações da Internet", depois "Serviços da World Wide Web" e, em seguida, "Recursos de Desenvolvimento de Aplicativos". Habilite os seguintes recursos:
Extensibilidade .NET
ASP.NET
É possível pré-compilar sites do ASP.NET usando a ferramenta de linha de comando aspnet_compiler.exe. Se você assinar os assemblies resultantes com uma chave, poderá implantar assemblies no GAC em vez de na pasta Bin do site.
No ASP.NET 4, se um site sendo executado em confiança parcial tentar carregar os assemblies do GAC, uma exceção "System.Security.SecurityException" será gerada. Isso ocorre porque, por padrão, o ASP.NET 4 usa uma implementação de CAS (segurança de acesso do código) mais recente do que as versões anteriores do ASP.NET. Na nova implementação de CAS, os assemblies pré-compilados e assinados que são implantados no GAC devem ser explicitamente marcados por meio do atributo "SecurityTransparent".
Para resolver esse problema:
Opção 1
--------
Antes de compilá-lo, marque o assembly usando o atributo "SecurityTransparent", como mostra o seguinte exemplo:
[assembly:System.Security.SecurityTransparentAttribute]
Opção 2
--------
Adicione uma configuração "compilerOptions" ao arquivo de configuração Web.config para o site, conforme é descrito no artigo "Como criar assemblies com versão atualizada para sites da Web pré-compilados" (http://msdn.microsoft.com/en-us/library/ms228042.aspx). Como parte desse processo, adicione a seguinte linha ao arquivo AssemblyInfo.vb ou AssemblyInfo.cs que é referenciado pela configuração "compilerOptions":
[assembly:System.Security.SecurityTransparentAttribute]
Opção 3
--------
Crie uma biblioteca de classes fictícia contendo o seguinte atributo:
[assembly:System.Security.SecurityTransparentAttribute]
Compile a biblioteca de classes em um assembly e execute a ferramenta de linha de comando aspnet_merge.exe na saída do site pré-compilado usando a opção "copyattrs", como mostra este exemplo:
aspnet_merge c:\MyApplicationRootDirectory -copyattrs assemblyfile.dll
Para o nome da DLL, use o nome da biblioteca de classes fictícia que é marcada com o atributo "SecurityTransparent".
Opção 4
--------
Reverta temporariamente para o modo de CAS mais antigo definindo o atributo "legacyCasModel" do elemento "trust" como "true" no arquivo Web.config para o site, como mostra este exemplo:
<trust level="Medium" legacyCasModel="true"/>
Depois de fazer essa alteração, é recomendável que você use uma das outras opções para adicionar o atributo "SecurityTransparent" a assemblies pré-compilados. Você poderá então remover o atributo "legacyCasModel" e executar o site no novo modo de CAS.
Se novas seções de configuração forem adicionadas ao arquivo Web.config de um aplicativo ASP.NET ou Windows Communication Foundation (WCF), o aplicativo não será iniciado quando estiver em execução no modo integrado do IIS 7.
Por exemplo, se uma seção de configuração <standardEndpoints> for adicionada ao arquivo Web.config de um aplicativo WCF, o aplicativo não será iniciado quando estiver em execução no modo integrado do IIS 7. Em vez disso, o IIS 7 retornará um erro de validação de configuração, pois a nova seção de configuração não é reconhecida pelo sistema de configuração do IIS 7.
Para resolver esse problema:
Baixe e instale um hotfix publicamente disponível para esse problema. O hotfix está disponível em http://support.microsoft.com/kb/958854. Outra opção é instalar o Windows Vista SP 2, que inclui a correção. O Windows 7 e o Windows Server 2008 R2 não apresentam esse problema porque esses sistemas operacionais já incluem a correção necessária.
O ASP.NET 4 deverá ser novamente registrado se o IIS 7/7.5 ou o recurso Extensibilidade .NET do IIS7/7.5 for habilitado *depois* que o .NET Framework 4 for instalado no computador. O ASP.NET 4 deverá ser novamente registrado se o recurso Extensibilidade .NET for removido quando o .NET Framework 4 estiver instalado no computador.
Para ambos os casos, é necessário um novo registro porque o processo de instalação e desinstalação do sistema operacional para o IIS7 e o IIS 7.5, bem como o recurso Extensibilidade .NET, não foi projetado para o cenário em que uma versão posterior do .NET Framework já existe no computador.
Para resolver esse problema:
Para registrar novamente o ASP.NET 4, execute o seguinte comando:
aspnet_regiis -iru -enable
Assegure-se de usar a versão do aspnet_regiis.exe que está instalada no diretório de instalação do .NET Framework 4.
A guia ASP.NET pode não ser exibida quando você executa o console de gerenciamento (MMC) em um computador local ao administrar um servidor Web remoto. Isso ocorre quando você usa a ferramenta de gerenciamento IIS 6 para gerenciar remotamente um servidor Web que tem o ASP.NET instalado, e quando o computador local está executando o Windows Server 2008 x64, o Windows 7 ou o Windows Server 2008 R2 (x86 ou x64).
Para resolver esse problema:
Não há nenhuma solução alternativa.
A execução da versão ASP.NET 2.0 do comando "aspnet_regiis -ua" no Windows Vista, no Windows Server 2008, no Windows 7 ou no Windows Server 2008 R2 causa o seguinte erro:
Não há suporte para a solicitação.
Isso ocorre porque a versão ASP.NET 2.0 do comando "aspnet_regiis" não consegue detectar que existe uma versão posterior do ASP.NET no computador.
Para resolver esse problema:
Execute a versão ASP.NET 4 do comando "aspnet_regiis -ua" para cancelar o registro de todas as versões do ASP.NET no computador.
No ASP.NET 2.0, o comando "aspnet_regiis -i" atualiza recursivamente todos os diretórios virtuais no Windows Server 2003 para que usem o ASP.NET 2.0. No ASP.NET 4, o comando "aspnet_regiis -i" no Windows Server 2003 atualiza somente a raiz do IIS 6 para ASP.NET 4. Se quaisquer diretórios virtuais abaixo da raiz forem explicitamente configurados para executar uma versão específica do ASP.NET, esses diretórios virtuais reterão a versão do ASP.NET que foi explicitamente configurada e não herdarão a configuração do ASP.NET 4 dos diretórios raiz.
Para resolver esse problema:
Execute as versões do ASP.NET 4 de qualquer um destes comandos:
aspnet_regiis -s
aspnet_regiis -r
Esses comandos forçam uma atualização recursiva de todos os diretórios virtuais para ASP.NET 4.
O cancelamento do registro do ASP.NET 2.0 em qualquer versão de sistema operacional em que o ASP.NET 4 já esteja registrado corrompe alguns registros dos contadores de desempenho no ASP.NET 4. Isso ocorre porque o processo de cancelamento de registro do ASP.NET 2.0 não consegue detectar que uma versão posterior do ASP.NET está instalada no computador. Com isso, quando você usa alguns contadores de desempenho do ASP.NET 4, podem aparecer erros como os seguintes no log de eventos do aplicativo:
"Não é possível localizar o procedimento de abertura "%pef_counter_name%" na DLL "%WINDOWS%\Microsoft.NET\Framework\v4.0.NNNNN\aspnet_perf.dll" para o serviço "ASP.NET"."
"Coleção de dados de contador de desempenho do serviço "ASP.NET" desativada devido a um ou mais erros gerados pela biblioteca do contador de desempenho para o serviço."
Para resolver esse problema:
Execute a versão ASP.NET 4 do comando "aspnet_regiis -iru". Esse procedimento registra novamente os contadores de desempenho do ASP.NET 4.
Por padrão, os projetos Web e os aplicativos Web do ASP.NET 4 baseados em instâncias de usuário do SQL Server Express não funcionam nos seguintes cenários:
Para resolver esse problema:
Para obter detalhes sobre como resolver esses problemas, consulte o artigo em
http://go.microsoft.com/fwlink/?LinkID=160102
No ASP.NET 4, o arquivo Web.config padrão foi significativamente reduzido em tamanho. Com isso, o IIS 7 (no Windows Vista e no Windows Server 2008) e o IIS 7.5 (no Windows Server 2008 R2) gerarão erros de configuração. Os erros exatos dependem das atualizações instaladas no sistema operacional e do tipo de informações de configuração contido nos arquivos Web.config em nível de aplicativo.
Windows Vista SP1 ou Windows Server 2008 SP1, onde não está instalado o hotfix KB958854 nem o SP2. Nessa configuração, o sistema de configuração do IIS 7 mescla incorretamente a configuração gerenciada de um aplicativo comparando o arquivo Web.config em nível de aplicativo aos arquivos machine.config do ASP.NET 2.0. Com isso, os arquivos Web.config em nível de aplicativo do .NET Framework 3.5 ou do .NET Framework 4 devem ter uma seção de configuração <system.web.extensions> para não causar uma falha de validação do IIS 7. As entradas do arquivo Web.config em nível de aplicativo manualmente modificadas que não corresponderem exatamente às definições da seção de configuração clichê original, que foram introduzidas com o Visual Studio 2008, causarão erros de configuração. (As entradas de configuração padrão geradas pelo Visual Studio 2008 não funcionam). Um problema comum é que os arquivos Web.config manualmente modificados omitem os atributos de configuração para "allowDefinition" e "requirePermission" que se encontram em várias definições da seção de configuração. Com isso, existe uma incompatibilidade entre a seção de configuração abreviada em arquivos Web.config em nível de aplicativo e a definição completa no arquivo machine.config do ASP.NET 4. Portanto, em tempo de execução, o sistema de configuração do ASP.NET 4 gera um erro de configuração.
Windows Vista SP2, Windows Server 2008 SP2, Windows 7, Windows Server 2008 R2, Windows Vista SP1 e Windows Server 2008 SP1, onde o hotfix KB958854 está instalado. Neste cenário, o sistema de configuração nativa do IIS 7 e do IIS 7.5 retorna um erro de configuração, pois ele faz uma comparação de textos no atributo "type" definido para um manipulador da seção de configuração gerenciada. Como todos os arquivos Web.config gerados pelo Visual Studio 2008 e pelo Visual Studio 2008 SP1 contêm "3.5" na cadeia de caracteres de tipo para as seções de configuração <system.web.extensions> (e relacionadas), e como o arquivo machine.config do ASP.NET 4 contém "4.0" no atributo "type" para as mesmas seções de configuração, os aplicativos gerados no Visual Studio 2008 ou no Visual Studio 2008 SP1 sempre falham na validação de configuração no IIS 7 e no IIS 7.5.
Para resolver esse problema:
Para o primeiro cenário, atualize o arquivo Web.config em nível de aplicativo incluindo o texto de configuração clichê de um arquivo Web.config que foi gerado automaticamente pelo Visual Studio 2008.
Para o segundo cenário, exclua ou comente todas as definições da seção de configuração <system.web.extensions> e as definições do grupo de seções de configuração do arquivo Web.config em nível de aplicativo.
O método System.Web.Hosting.IProcessHostPreloadClient.Preload utiliza uma matriz de cadeia de caracteres como um parâmetro de entrada. Entretanto, não há um meio de definir esses dados, e nenhuma informação é passada nesse parâmetro.
Para resolver esse problema:
Versões prévias do recurso de início automático do IIS 7.5 ofereciam suporte a uma forma de configurar um ou mais valores de cadeia de caracteres a serem passados para o método IProcessHostPerloadClient.Preload do ASP.NET 4. Entretanto, essa funcionalidade foi removida antes da versão final do Windows 7 e do Windows Server 2008 R2.
O recurso Extensibilidade .NET do IIS 7 e do IIS 7.5 é uma opção de configuração que está disponível na caixa de diálogo "Recursos do Windows" para instalar ou desinstalar recursos do IIS 7 ou do IIS 7.5. O recurso está localizado no seguinte nó:
Serviços de Informações da Internet > Serviços da World Wide Web > Recursos de Desenvolvimento de Aplicativos > Extensibilidade .NET
No Windows Vista, no Windows Server 2008, no Windows 7 e no Windows Server 2008 R2, o recurso Extensibilidade .NET afeta somente a integração do ASP.NET 2.0 com o IIS 7 ou o IIS 7.5. Ele não afeta o registro ou o cancelamento do registro do ASP.NET 4 com o IIS 7 ou o IIS 7.5.
Para resolver esse problema:
Para gerenciar a integração do ASP.NET 4 com o IIS 7 ou o IIS 7.5, use a versão ASP.NET 4 do comando "aspnet_regiis.exe".
Os aplicativos ASP.NET 2.0 executados no IIS 6 (Windows Server 2003 ou Windows Server 2003 R2) podem gerar erros como este:
System.Web.HttpException: Path '/[RaizDoAplicativo]/eurl.axd/[Valor]' não encontrado.
Esse erro ocorre somente depois que o ASP.NET 4 é habilitado no IIS 6. Ele ocorre porque, quando o ASP.NET detecta que um site está configurado para usar o ASP.NET 4, um componente nativo do ASP.NET 4 passa URLs sem extensão para a parte gerenciada do ASP.NET para processamento adicional.
Entretanto, se os diretórios virtuais que estiverem em um site do ASP.NET 4 estiverem configurados para usar o ASP.NET 2.0, o processamento de URLs sem extensão dessa forma criará uma URL modificada contendo "eurl.axd", que é então enviada ao aplicativo ASP.NET 2.0. O ASP.NET 2.0 não reconhece o formato "eurl.axd". Portanto, o ASP.NET 2.0 tenta localizar um arquivo denominado "eurl.axd" e executá-lo. Como não existe tal arquivo, a solicitação falha com uma exceção "HttpException".
Para resolver esse problema:
Opção 1
--------
Se o ASP.NET 4 não for necessário para executar o site, remapeie o site para usar então o ASP.NET 2.0.
Opção 2
---------
Se o ASP.NET 4 for necessário para executar o site, mova quaisquer diretórios virtuais filho do ASP.NET 2.0 para outro site que esteja mapeado para o ASP.NET 2.0.
Opção 3
---------
Se não for prático remapear o site para o ASP.NET 2.0 ou alterar a localização de um diretório virtual, desabilite explicitamente o processamento de URLs sem extensão no ASP.NET 4. Use o seguinte procedimento:
1. No Registro do Windows, abra o seguinte nó:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\4.0.<build#>
Observação: <build#> é o número da compilação da versão de lançamento do .NET Framework 4.
2. Crie um valor DWORD denominado "EnableExtensionlessUrls".
3. Defina "EnableExtensionlessUrls" como 0. Isso desabilita o comportamento de URLs sem extensão.
4. Salve o valor do Registro e feche o Editor do Registro.
5. Execute a ferramenta de linha de comando "iisreset", que faz com que o IIS leia o novo valor do Registro.
Observação: a definição de "EnableExtensionlessUrls" como 1 habilita o comportamento de URLs sem extensão. Essa será a configuração padrão se nenhum valor for especificado.
Referências a namespaces e assemblies exigidas por projetos Web que usam o Entity Framework foram removidas da versão RTM do arquivo Web.config raiz. Com isso, sites de Dados Dinâmicos que usam EntityDataSource, bem como aplicativos Web que usam o Entity Framework e foram criados com versões de pré-lançamento do ASP.NET 4, irão falhar e relatar erros de compilação.
Para resolver esse problema:
Você poderá inserir as referências a assemblies e namespaces ausentes no arquivo Web.config do aplicativo. O exemplo a seguir mostra os elementos assembly e namespace que devem ser manualmente inseridos no arquivo Web.config em nível de aplicativo.
<system.web>
<compilation>
<assemblies>
<add assembly="System.Data.Entity, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
<add assembly="System.Web.Entity, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"/>
<add assembly="System.Data.Linq, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
<add assembly="System.Data.Entity.Design, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
</assemblies>
</compilation>
<pages>
<namespaces>
<add namespace="System.Data.Entity.Design" />
<add namespace="System.Data.Linq" />
</namespaces>
</pages>
</system.web>
Em determinadas ordens de instalação do .NET Framework versões 2.0 e 4 no Windows Vista, no Windows Server 2008, no Windows 7 e no Windows Server 2008 R2, os aplicativos ASP.NET 4 geram um erro NullReferenceException sem tratamento na classe RoleManagerModule. Isso ocorre quando o ASP.NET 4 é a única versão do ASP.NET que está sendo registrada com o IIS 7 ou o IIS 7.5, e o ASP.NET 2.0 nunca foi registrado com o IIS, ou o ASP.NET 2.0 foi registrado no IIS 7 ou no IIS 7.5.
Qualquer que seja o cenário, o registro autônomo do ASP.NET 4 resulta na ordem incorreta no arquivo de configuração para dois módulos HTTP que são usados em aplicativos no modo integrado.
Para resolver esse problema:
Embora esse problema esteja corrigido na versão de lançamento do ASP.NET 4, as versões de pré-lançamento do ASP.NET 4 podem ter especificado a ordem incorreta dos módulos. Se a exceção sem tratamento ainda estiver ocorrendo em um computador que tenha sido atualizado da versão de pré-lançamento do ASP.NET 4 para a versão RTM, siga estas etapas:
1. Abra o arquivo applicationHost.config, que está na seguinte pasta:
%windir%\System32\inetsrv\config
2. Localize o elemento a seguir
<location path="" overrideMode="Allow">
Nesse elemento está a lista de módulos HTTP do modo integrado. As informações estão no elemento <modules>.
3. Localize o elemento que começa com a seguinte cadeia de caracteres:
<add name="RoleManager" ...
4. Mova o elemento para baixo do elemento que começa com a seguinte cadeia de caracteres:
<add name="DefaultAuthentication"...
5. Salve o arquivo.
Quando você terminar, uma parte da definição <modules> deverá ser semelhante ao seguinte exemplo:
<add name="DefaultAuthentication" type="System.Web.Security.DefaultAuthenticationModule" preCondition="managedHandler" />
<add name="RoleManager" type="System.Web.Security.RoleManagerModule" preCondition="managedHandler" />
Os aplicativos MVC 2 e ASP.NET 4 Web Forms que usam URLs sem extensão poderão retornar erros HTTP 404 quando executados no Windows Vista, no Windows Server 2008, no Windows 7 ou no Windows Server 2008 R2. Essa situação pode ocorrer somente quando a opção Extensibilidade .NET Framework está ativa enquanto o IIS é instalado por meio da caixa de diálogo Recursos do Windows. Uma instalação mínima do IIS não incluirá determinados módulos HTTP. Devido à forma como o ASP.NET e o IIS gerenciam transições de eventos de pipeline HTTP, os módulos HTTP ausentes impedem que o módulo de encaminhamento de URLs do ASP.NET seja executado no momento adequado. Com isso, as solicitações de URLs sem extensão não são processadas pelo módulo de encaminhamento de URLs, e ocorre um erro 404.
Para resolver esse problema:
Na caixa de diálogo "Ativar ou desativar recursos do Windows" do aplicativo "Programas e Recursos" do Painel de Controle do Windows,
execute as seguintes etapas:
1. Navegue até o seguinte nó:
Serviços de Informações da Internet --> Serviços da World Wide Web --> Recursos HTTP Comuns
2. Verifique se a opção "Redirecionamento de Erros HTTP" está selecionada.
-ou-
1. Navegue até o seguinte nó:
Serviços de Informações da Internet --> Serviços da World Wide Web --> Recursos de Desempenho
2. Verifique se a opção "Compactação de Conteúdo Estático" está selecionada.
Após as opções serem selecionadas, clique em "OK" para salvar as alterações.
A reabilitação do módulo Redirecionamento HTTP ou Compactação de Conteúdo Estático assegura que o ASP.NET e o IIS sincronizem corretamente os eventos de pipeline HTTP. Isso permite que o módulo de encaminhamento de URLs processe URLs sem extensão.
Em versões anteriores do ASP.NET, uma referência ao assembly System.Web.Mobile.dll era incluída no arquivo Web.config raiz da seção <assemblies> em <system.web><compilation>. Para melhorar o desempenho, a referência ao assembly foi removida.
Para resolver esse problema:
O assembly System.Web.Mobile.dll está incluído no ASP.NET 4, mas foi preterido. Se desejar usar tipos do assembly System.Web.Mobile.dll, adicione uma referência a esse assembly, no arquivo Web.config raiz ou em um arquivo Web.config de aplicativo. Por exemplo, se desejar usar qualquer um dos controles móveis do ASP.NET (preteridos), você deverá adicionar ao arquivo Web.config uma referência ao assembly System.Web.Mobile.dll.
Os arquivos de definição do navegador foram atualizados para conter informações sobre navegadores e dispositivos novos e atualizados. Navegadores e dispositivos mais antigos, como o Netscape Navigator, foram removidos e outros mais novos, como o Google Chrome e o Apple iPhone, foram adicionados.
Para resolver esse problema:
Você poderá usar os arquivos antigos de definição do navegador com o ASP.NET 4. Esses arquivos, e a respectiva documentação de instalação, estão contidos na versão dos Arquivos de Definição do Navegador ASP.NET em http://go.microsoft.com/fwlink/?LinkID=186493.
As versões localizadas dos arquivos Microsoft Ajax JavaScript, como o MicrosoftAjax.debug.ja.js, não serão adicionadas à CDN (rede de distribuição de conteúdo) do Microsoft Ajax até o lançamento das versões localizadas do .NET Framework 4. Portanto, não habilite a propriedade ScriptManager.EnableCdn quando estiver usando uma versão localizada do .NET Framework e da CDN.
Para resolver esse problema:
Aguarde o lançamento das versões localizadas do .NET Framework 4 para usar a CDN (rede de distribuição de conteúdo) do Microsoft Ajax. Enquanto isso, assegure-se de que os controles ScriptManager no seu aplicativo não tenham EnableCdn="true".
Após a instalação do ASP.NET 4, os contadores de desempenho genéricos do ASP.NET relatarão dados somente de aplicativos ASP.NET 4. Se os contadores de desempenho genéricos forem usados nos aplicativos ASP.NET 1.1, ASP.NET 2.0 e ASP.NET 3.5, os contadores de desempenho não relatarão dados. Os dados de desempenho de aplicativos que executam versões anteriores do ASP.NET devem usar categorias de desempenho do ASP.NET com versão.
Os contadores de desempenho genéricos do ASP.NET incluem as seguintes categorias de contadores de desempenho: "ASP.NET" e "Aplicativos do ASP.NET".
As categorias de desempenho do ASP.NET com versão possuem nomes semelhantes a estes: "ASP.NET v2.0.50727" e "ASP.NET Apps v2.0.50727".
Para resolver esse problema:
Esse comportamento é definido por design. A versão mais recente do ASP.NET instalada em um computador "possui" as categorias de contadores de desempenho genéricas. Portanto, é recomendável que você use categorias de contadores de desempenho com versão ao coletar dados de desempenho de vários aplicativos ASP.NET que executam diferentes versões do ASP.NET.
Não existem problemas conhecidos.
Não existem problemas conhecidos.
Não existem problemas conhecidos.
Não existem problemas conhecidos.
Não existem problemas conhecidos.
Após a atualização do .NET Framework 4 para a versão RTM a partir da versão Beta 2, poderá ocorrer o seguinte erro quando você iniciar serviços ou reiniciar o IIS:
"O sistema não pode encontrar o arquivo especificado"
Para resolver esse problema:
Repare o .NET Framework Client Profile no aplicativo Programas no painel de controle.
Assemblies do WPF não são instalados nem têm suporte em computadores ia64.
Para resolver esse problema:
Não há nenhuma solução alternativa. O WPF não pode ser usado em ia64.
Quando um fluxo de trabalho que inclui o operador sizeof é validado, uma exceção é gerada.
Para resolver esse problema:
Não use o operador sizeof em fluxos de trabalho.
Não há suporte para o .NET Framework 4 Client Profile em ia64.
Para resolver esse problema:
Se você desinstalar o .NET Framework 4 em ia64, assegure-se de desinstalar as versões Full e Client Profile.
© 2010 Microsoft Corporation. Todos os direitos reservados.
Termos de Uso | Marcas Comerciais | Declaração de Privacidade