Para obtener la versión más reciente del archivo Léame, haga clic aquí.
Este problema puede producirse en los siguientes escenarios:
El texto completo del error es el siguiente:
No se pudo cargar el tipo 'System.ServiceModel.Activation.HttpModule' del ensamblado 'System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'.
Descripción: Excepción no controlada al ejecutar la solicitud web actual. Revise el seguimiento de la pila para obtener más información acerca del error y dónde se originó en el código.
Para resolver este problema:
En un equipo que tiene IIS 7 o IIS 7.5 habilitado y .NET Framework 4 instalado, la desinstalación de la versión Beta 2 deja entradas "isapiCgiRestriction" sin usar en el archivo applicationHost.config. Esto ocurre en Windows Vista, Windows Server 2008 y Windows 7. Las entradas no usadas no afectan a la funcionalidad del servidor web. Versiones posteriores de .NET Framework 4 se pueden instalar con seguridad en el mismo equipo, porque instalaciones subsecuentes actualizarán las entradas "isapiCgiRestriction".
Para resolver este problema:
Elimine las entradas "isapiCgiRestriction" no usadas del archivo applicationHost.config. No obstante, este paso no es necesario, porque las entradas que se dejan después de la desinstalación no afectan a la funcionalidad del producto ni a la posibilidad de instalar versiones posteriores.
.NET Framework 1.0 no se puede instalar después de instalar .NET Framework 4 .NET Framework 1.0 debe instalarse antes de instalar .NET Framework 4
Para resolver este problema:
El programa de instalación de .NET Framework 4 no pudo realizar la instalación.
Para resolver este problema:
Consulte la guía de solución de problemas de instalación de .NET Framework 4 (http://go.microsoft.com/fwlink/?LinkId=186690)
El servicio de almacenamiento en caché de las fuentes de Windows Presentation Foundation (WPF) 4 no se desinstala completamente al desinstalar .NET Framework 4 (.NET Framework completo).
Nota: este problema afecta tanto a la versión completa como a la versión Client Profile de .NET Framework.
Para resolver este problema:
Se debe mostrar “[SC] DeleteService SUCCESS”.
Al actualizar la consola de servicios, no debe aparecer la caché de fuentes. Si con esta actualización no se resuelve el problema, reinicie el equipo.
NET Framework 1.0 no se puede instalar después de instalar .NET Framework 4 Client Profile. .NET Framework 1.0 debe instalarse antes de instalar .NET Framework 4 Client Profile.
Para resolver este problema:
Al desinstalar .NET Framework 4, es posible que el servicio de almacenamiento en caché de las fuentes de WPF no se desinstale completamente.
Aunque el servicio de almacenamiento en caché de las fuentes de WPF no se puede utilizar después de la instalación, la entrada de servicio “Windows Presentation Foundation Font Cache 4.0.0.0” sigue apareciendo en la consola de servicios.
En Windows Vista y Windows Server 2008, el campo “Descripción” de la consola de servicios indicará: “<Error al leer la descripción. Código de error: 2 >”. En Windows XP y Windows Server 2003, en el campo “Descripción” se seguirá mostrando la cadena correcta.
Este problema se soluciona reinstalando .NET Framework. No se conoce ningún otro efecto.
Nota: este problema afecta tanto a la versión Client Profile completa como a la versión completa de .NET Framework.
Para resolver este problema:
Se debe mostrar “[SC] DeleteService SUCCESS”.
Al actualizar la consola de servicios, no debe aparecer la caché de fuentes. Si con esta actualización no se resuelve el problema, reinicie el equipo.
El programa de instalación de .NET Framework 4 Client Profile no pudo realizar la instalación
Para resolver este problema:
Consulte la guía de solución de problemas de instalación de .NET Framework 4 (http://go.microsoft.com/fwlink/?LinkId=186690)
En un equipo que tiene IIS 7 o IIS 7.5 habilitado y .NET Framework 4 instalado, la desinstalación de la versión Beta 2 deja entradas "isapiCgiRestriction" sin usar en el archivo applicationHost.config. Esto ocurre en Windows Vista, Windows Server 2008 y Windows 7. Las entradas no usadas no afectan a la funcionalidad del servidor web. Versiones posteriores de .NET Framework 4 se pueden instalar con seguridad en el mismo equipo, porque instalaciones subsecuentes actualizarán las entradas "isapiCgiRestriction".
Para resolver este problema:
Elimine las entradas "isapiCgiRestriction" no usadas del archivo applicationHost.config. No obstante, este paso no es necesario, porque las entradas que se dejan después de la desinstalación no afectan a la funcionalidad del producto ni a la posibilidad de instalar versiones posteriores.
La solución para desinstalar completamente este servicio huérfano es:
Debe aparecer: “[SC] DeleteService SUCCESS”.
Al actualizar la consola de servicios, no debe aparecer el servicio. Es posible que sea necesario reiniciar el equipo si el problema no se resuelve actualizando la consola de servicios.
(Nota: este problema se produce con la desinstalación de la versión completa de .NET Framework y es una copia del problema 877240 del archivo Readme correspondiente a Client Profile )
Para resolver este problema:
La solución para desinstalar completamente este servicio huérfano es:
Debe aparecer: “[SC] DeleteService SUCCESS”.
Al actualizar la consola de servicios, no debe aparecer el servicio. Es posible que sea necesario reiniciar el equipo si el problema no se resuelve actualizando la consola de servicios.
Al desinstalar .NET 4.0 de Vista/XP/w2k3/W2k8 el servicio de almacenamiento en caché de las fuentes de WPF no se desinstala completamente.
Aunque el servicio de almacenamiento en caché de las fuentes de WPF no se puede utilizar después de la instalación, la entrada de servicio “Windows Presentation Foundation Font Cache 4.0.0.0” sigue apareciendo en la consola de servicios.
En Vista y W2k8, el campo “Descripción” de la consola de servicios indicará: “<Error al leer la descripción. Código de error: 2 >”. En Windows XP y Windows Server 2003, en el campo “Descripción” se seguirá mostrando la cadena correcta.
Este problema se soluciona reinstalando .NET Framework. No se conoce ningún otro efecto.
Nota: este problema se produce en Net4 Client Profile y en la versión completa de NET4.
Para resolver este problema:
La solución para desinstalar completamente este servicio huérfano es:
Debe aparecer: “[SC] DeleteService SUCCESS”.
Al actualizar la consola de servicios, no debe aparecer el servicio. Es posible que sea necesario reiniciar el equipo si el problema no se resuelve actualizando la consola de servicios.
(Nota: este problema se produce con Client Profile y es una copia del problema 888322 del archivo Readme correspondiente a la versión completa).
Es posible que aparezca un error de compilación si utiliza las versiones de chino simplificado y chino tradicional de Visual Studio 2010 para publicar una aplicación, y activó la opción ‘Descargar los requisitos previos desde la misma ubicación que mi aplicación' en el cuadro de diálogo Requisitos previos y seleccionó alguno de los componentes siguientes como requisitos previos:
Este es el error de compilación que puede aparecer para ‘Microsoft .NET Framework 4 Client Profile (x86 y x64)’:
'MSB3152: La ubicación de la instalación de los requisitos previos no se ha establecido en el 'sitio web del proveedor de componentes' y no se encuentra el archivo 'DotNetFX40Client\dotNetFx40LP_Client_x86_x64cs.exe' del elemento 'Microsoft .NET Framework 4 Client Profile (x86 y x64)' en el disco. Vea la Ayuda para obtener más información'.
Para solucionar este problema:
Para solucionar este problema con la versión de chino simplificado, siga estos pasos:
<String Name=”Culture”>zh-chs</String>
Para solucionar este problema con la versión de chino tradicional, siga estos pasos:
<String Name=”Culture”>zh-cht</String>
Es posible que no se puedan instalar los paquetes de idioma de chino simplificado y chino tradicional si utiliza las versiones de chino simplificado o chino tradicional de Visual Studio 2010 para publicar una aplicación, y activó la opción 'Descargar los requisitos previos del sitio web del proveedor de los componentes' en el cuadro de diálogo Requisitos previos y seleccionó alguno de los componentes siguientes como requisitos previos:
Para solucionar este problema:
Para solucionar este problema con la versión de chino simplificado, siga estos pasos:
<String Name=”Culture”>zh-chs</String>
Para solucionar este problema con la versión de chino tradicional, siga estos pasos:
<String Name=”Culture”>zh-cht</String>
Después de instalar .NET Framework 4 en un equipo cliente o servidor que ejecute Windows 7 y que tenga IIS 7.5 habilitado, la opción para configurar archivos de configuración de ASP.NET para diferentes grupos de aplicaciones deja de funcionar. Esto ocurre porque la instalación de .NET Framework 4 produce un ligero cambio en el comportamiento predeterminado de la inicialización de Common Language Runtime (CLR). Cuando se instala .NET Framework 4, IIS 7.5 en Windows 7 llama a un archivo DLL nativo de ASP.NET 4 para llevar a cabo la inicialización de CLR y esta lógica de inicialización no permite el uso de archivos de configuración diferentes.
Para resolver este problema:
Puesto que la lógica de inicialización de CLR es básicamente la misma para .NET Framework 4 y para IIS 7.5 (excepto por el efecto secundario de los archivos de configuración), puede configurar de nuevo IIS 7.5 para que deje de delegar la inicialización de CLR en ASP.NET 4. Esto puede hacerse de dos maneras.
Opción 1
----------
En el archivo applicationHost.config de IIS 7.5, establezca el valor predeterminado del atributo "managedRuntimeLoader" en una cadena vacía, como en el ejemplo siguiente:
<applicationPools>
<applicationPoolDefaults managedRuntimeLoader="" />
</applicationPools>
Opción 2
----------
En el archivo IIS_Schema.xml de IIS 7.5, establezca "defaultValue" en el atributo "managedRuntimeLoader" en una cadena vacía. Por ejemplo, el atributo podría ser originalmente parecido al siguiente ejemplo:
<attribute name="managedRuntimeLoader" type="string" defaultValue="webengine4.dll" />
Cámbielo del siguiente modo:
<attribute name="managedRuntimeLoader" type="string" defaultValue="" />
En Windows XP y Windows Server 2003 (todas las versiones), si anula el registro de ASP.NET 4 de IIS y vuelve a registrarlo, la consola MMC de IIS muestra un valor vacío para la lista de versiones de ASP.NET en la ficha ASP.NET. La siguiente secuencia de pasos dará lugar a este problema:
Para resolver este problema:
En la lista de versiones de ASP.NET en la consola MMC de IIS, seleccione manualmente la versión de ASP.NET que desea y haga clic en el botón "Aplicar".
Algunas tareas de compilación de ASP.NET en Windows Vista, Windows Server 2008 y Windows 7 pueden dar error porque el proceso de trabajo de IIS no tiene permisos de escritura en el directorio temporal de Windows (%WINDOWS%\Temp). Si intenta compilar elementos como referencias de servicios Web que dependen de archivos WSDL, pueden producirse errores como "Mensaje de error del analizador: No se puede generar una clase temporal".
Este error se produce si IIS está habilitado en el equipo y está instalado .NET Framework 4, pero las características ASP.NET y Extensibilidad de .NET no se han habilitado.
Para resolver este problema:
Opción 1
----------
Conceda permisos de escritura de forma explícita a la cuenta del proceso de trabajo de IIS para el directorio temporal de Windows (%WINDOWS%\Temp). Una forma de hacer esto es conceder acceso de escritura a un grupo que incluya la cuenta del proceso de trabajo, por ejemplo, el grupo IIS_IUSRS.
Opción 2
---------
Habilite las características ASP.NET y Extensibilidad de .NET. En el Panel de control de Windows, abra "Programas" y, en "Programas y características", haga clic en "Activar o desactivar las características de Windows". En el cuadro de diálogo "Características de Windows", abra el nodo "Internet Information Services", elija "Servicios World Wide Web" y después "Características de desarrollo de aplicaciones". Habilite las siguientes características:
Extensibilidad de .NET
ASP.NET
Puede precompilar sitios web de ASP.NET usando la herramienta de la línea de comandos aspnet_compiler.exe. Si firma los ensamblados resultantes con una clave, puede implementar ensamblados en GAC en lugar de la carpeta Bin del sitio web.
En ASP.NET 4, si un sitio web que se ejecuta con confianza parcial intenta cargar los ensamblados desde GAC, se produce una excepción "System.Security.SecurityException". Esto ocurre porque, de forma predeterminada, ASP.NET 4 usa una implementación de CAS (seguridad de acceso del código) más reciente que versiones anteriores de ASP.NET. En la nueva implementación de CAS, los ensamblados precompilados y firmados que se han implementado en GAC deben marcarse de forma explícita con el atributo "SecurityTransparent".
Para resolver este problema:
Opción 1
--------
Antes de compilarlo, marque el ensamblado usando el atributo "SecurityTransparent", como se muestra en el ejemplo siguiente:
[assembly:System.Security.SecurityTransparentAttribute]
Opción 2
--------
Agregue un valor "compilerOptions" al archivo Web.config para el sitio, como se explica en el artículo "Cómo: Crear ensamblados que tienen versión para sitios web precompilados" (http://msdn.microsoft.com/en-us/library/ms228042.aspx). Como parte de este proceso, agregue la siguiente línea al archivo AssemblyInfo.vb o AssemblyInfo.cs al que se hace referencia en el valor "compilerOptions":
[assembly:System.Security.SecurityTransparentAttribute]
Opción 3
--------
Cree una biblioteca de clases ficticia que contenga el siguiente atributo:
[assembly:System.Security.SecurityTransparentAttribute]
Compile la biblioteca de clases en un ensamblado y ejecute la herramienta de la línea de comandos aspnet_merge.exe en la salida del sitio web precompilado usando la opción "copyattrs", como se muestra en el ejemplo siguiente:
aspnet_merge c:\MyApplicationRootDirectory -copyattrs assemblyfile.dll
Para el nombre del archivo DLL, use el nombre de la biblioteca de clases ficticia marcada con el atributo "SecurityTransparent".
Opción 4
--------
Revierta temporalmente al modo de CAS anterior estableciendo el atributo "legacyCasModel" del elemento "trust" en "true" en el archivo Web.config para el sitio, como se muestra en el ejemplo siguiente:
<trust level="Medium" legacyCasModel="true"/>
Tras realizar este cambio, se recomienda usar una de las otras opciones para agregar el atributo "SecurityTransparent" a ensamblados precompilados. A continuación, puede quitar el atributo "legacyCasModel" y ejecutar el sitio web en el nuevo modo de CAS.
Si se agregan nuevas secciones de configuración al archivo Web.config de una aplicación de ASP.NET o Windows Communication Foundation (WCF), la aplicación no se iniciará cuando se ejecute en modo integrado de IIS 7.
Por ejemplo, si se agrega una sección de configuración <standardEndpoints> al archivo Web.config de una aplicación WCF, la aplicación no se iniciará cuando se ejecute en modo integrado de IIS 7. En su lugar, IIS 7 devolverá un error de validación, porque la nueva sección de configuración no se reconoce en el sistema de configuración de IIS 7.
Para resolver este problema:
Descargue e instale una revisión disponible públicamente para este problema. La revisión está disponible en http://support.microsoft.com/kb/958854. También puede instalar Windows Vista SP 2, que incluye esta revisión. Windows 7 y Windows Server 2008 R2 no tienen este problema, porque estos sistemas operativos ya incluyen la revisión necesaria.
ASP.NET 4 debe registrarse de nuevo si IIS 7/7.5 o la característica Extensibilidad de .NET de IIS7/7.5 se habilita *después* de haber instalado .NET Framework 4 en el equipo. ASP.NET 4 también debe registrarse de nuevo si se quita la característica Extensibilidad de .NET cuando .NET Framework 4 está instalado en el equipo.
En ambos casos, es necesario repetir el registro porque el proceso de instalación y desinstalación del sistema operativo para IIS7 e IIS 7.5 y para la característica Extensibilidad de .NET no se diseñó para el escenario en que ya exista una versión posterior de .NET Framework en el equipo.
Para resolver este problema:
Para registrar de nuevo ASP.NET 4, ejecute el siguiente comando:
aspnet_regiis -iru -enable
Asegúrese de que usa la versión de aspnet_regiis.exe instalada en el directorio de instalación de .NET Framework 4.
Puede que no aparezca la pestaña de ASP.NET si ejecuta la consola de administración (MMC) en un equipo local cuando administra un servidor web remoto. Esto ocurre cuando se usa la herramienta de administración de IIS 6 para administrar en modo remoto un servidor web que tiene ASP.NET instalado y cuando el equipo local está ejecutando Windows Server 2008 x64, Windows 7 o Windows Server 2008 R2 (x86 o x64).
Para resolver este problema:
No se puede solucionar.
Al ejecutar la versión de ASP.NET 2.0 del comando "aspnet_regiis -ua" en Windows Vista, Windows Server 2008, Windows 7 o Windows Server 2008 R2, se produce el siguiente error:
La solicitud no se admite.
Esto se produce porque la versión de ASP.NET 2.0 del comando "aspnet_regiis" no puede detectar que existe una versión posterior de ASP.NET en el equipo.
Para resolver este problema:
2.3.2.8 Al ejecutar la versión de ASP.NET 2.0 de "aspnet_regiis -ua", no anula el registro de otras versiones de ASP.NET, incluido ASP.NET 4
Para ASP.NET 2.0, el comando "aspnet_regiis -i" actualiza de forma recursiva todos los directorios virtuales en Windows Server 2003 para usar ASP.NET 2.0. Para ASP.NET 4, el comando "aspnet_regiis -i" en Windows Server 2003 actualiza sólo la raíz de IIS 6 a ASP.NET 4. Si se establecen directorios virtuales bajo la raíz de forma explícita para que ejecuten una versión específica de ASP.NET, esos directorios virtuales mantienen la versión de ASP.NET establecida de forma explícita en lugar de heredar el valor ASP.NET 4 de los directorios raíz.
Para resolver este problema:
Ejecute la versión de ASP.NET 4 de alguno de los comandos siguientes:
aspnet_regiis -s
aspnet_regiis -r
Estos comandos fuerzan una actualización recursiva de todos los directorios virtuales a ASP.NET 4.
Al anular el registro de ASP.NET 2.0 en cualquier versión del sistema operativo donde ya esté registrado ASP.NET 4, se daña el registro de algunos contadores de rendimiento de ASP.NET 4. Esto se produce porque el proceso de anulación del registro de ASP.NET 2.0 no puede detectar que hay una versión posterior de ASP.NET instalada en el equipo. Como resultado, si usa determinados contadores de rendimiento de ASP.NET 4, pueden aparecer errores como los siguientes en el registro de eventos de la aplicación:
"No se encuentra el procedimiento "%pef_counter_name%" en el archivo DLL "%WINDOWS%\Microsoft.NET\Framework\v4.0.NNNNN\aspnet_perf.dll" para el servicio "ASP.NET"".
"Se deshabilitó la recopilación de datos de los contadores de rendimiento del servicio "ASP.NET" debido a uno o más errores generados por la biblioteca de contadores de rendimiento de este servicio."
Para resolver este problema:
Ejecute la versión ASP.NET 4 del comando "aspnet_regiis -iru". Esto registra de nuevo los contadores de rendimiento de ASP.NET 4.
De forma predeterminada, los proyectos y aplicaciones web de ASP.NET 4 que se basan en instancias de usuario de SQL Server Express no funcionan en los siguientes escenarios:
Para resolver este problema:
Para obtener información detallada sobre cómo solucionar estos problemas, vea este artículo:
http://go.microsoft.com/fwlink/?LinkID=160102
En ASP.NET 4, se ha reducido notablemente el tamaño del archivo Web.config predeterminado. Como resultado, IIS 7 (en Windows Vista y Windows Server 2008) e IIS 7.5 (en Windows Server 2008 R2) producirán errores de configuración. Los errores exactos dependen de las actualizaciones que se hayan instalado en el sistema operativo y del tipo de información de configuración que contienen los archivos Web.config de nivel de aplicación.
Windows Vista SP1 o Windows Server 2008 SP1, donde no está instalada la revisión KB958854 ni el Service Pack 2. En esta configuración, el sistema de configuración de IIS 7 combina erróneamente la configuración administrada de una aplicación comparando el archivo Web.config de nivel de aplicación con los archivos machine.config de ASP.NET 2.0. Debido a esto, los archivos Web.config de nivel de aplicación de .NET Framework 3.5 o .NET Framework 4 deben tener una sección de configuración <system.web.extensions> para no producir un error de validación de IIS 7. Las entradas del archivo Web.config de nivel de aplicación modificadas manualmente que no coinciden exactamente con las definiciones de la sección de configuración reutilizable original introducidas con Visual Studio 2008 producirán errores de configuración. (Las entradas de configuración predeterminadas generadas por Visual Studio 2008 no funcionan). Un problema común es que los archivos Web.config modificados manualmente excluyen los atributos de configuración para "allowDefinition" y "requirePermission" que se encuentran en varias definiciones de la sección de configuración. Como resultado, hay una incoherencia entre la sección de configuración abreviada de los archivos Web.config de nivel de aplicación y la definición completa del archivo machine.config de ASP.NET 4. Por tanto, en tiempo de ejecución, el sistema de configuración de ASP.NET 4 produce un error de configuración.
Windows Vista SP2, Windows Server 2008 SP2, Windows 7, Windows Server 2008 R2 y también Windows Vista SP1 y Windows Server 2008 SP1 donde está instalada la revisión KB958854. En este escenario, el sistema de configuración nativo de IIS 7 e IIS 7.5 devuelve un error de configuración porque lleva a cabo una comparación en el atributo "type" definido para un controlador de la sección de configuración administrada. Puesto que todos los archivos Web.config generados por Visual Studio 2008 y Visual Studio 2008 SP1 tienen "3.5" en la cadena de tipo para las secciones de configuración <system.web.extensions> (y relacionas), y puesto que el archivo machine.config de ASP.NET 4 tiene "4.0" en el atributo "type" para las mismas secciones de configuración, las aplicaciones generadas en Visual Studio 2008 o Visual Studio 2008 SP1 dan error siempre en la validación de configuración en IIS 7 e IIS 7.5.
Para resolver este problema:
Para el primer escenario, actualice el archivo Web.config de nivel de aplicación incluido el texto de configuración reutilizable de un archivo Web.config generado automáticamente por Visual Studio 2008.
Para el segundo escenario, elimine o ponga marcas de comentario en todas las definiciones de la sección de configuración <system.web.extensions> y las definiciones del grupo de secciones de configuración del archivo Web.config de nivel de aplicación.
El método System.Web.Hosting.IProcessHostPreloadClient.Preload toma una matriz de cadenas como parámetro de entrada. Sin embargo, no hay forma de establecer estos datos y nunca se pasa información en este parámetro.
Para resolver este problema:
Versiones preliminares anteriores de la característica de inicio rápido de IIS 7.5 incluían un modo de configurar uno o varios valores de cadena para pasarlos al método IProcessHostPerloadClient.Preload de ASP.NET 4. Sin embargo, esa funcionalidad se quitó antes de la versión final de Windows 7 y Windows Server 2008 R2.
La característica Extensibilidad de .NET de IIS 7 e IIS 7.5 es una opción de configuración disponible en el cuadro de diálogo "Características de Windows" para instalar o desinstalar características de IIS 7 o IIS 7.5. La característica se encuentra en el siguiente nodo:
Internet Information Services > Servicios de World Wide Web > Características de desarrollo de aplicaciones > Extensibilidad de .NET
En Windows Vista, Windows Server 2008, Windows 7 y Windows Server 2008 R2, la característica Extensibilidad de .NET afecta únicamente a la integración de ASP.NET 2.0 con IIS 7 o IIS 7.5. No tiene efecto a la hora de registrar o anular el registro de ASP.NET 4 en IIS 7 o IIS 7.5.
Para resolver este problema:
Para administrar la integración de ASP.NET 4 con IIS 7 o IIS 7.5, use la versión de ASP.NET 4 del comando "aspnet_regiis.exe".
Las aplicaciones de ASP.NET 2.0 que se ejecutan en IIS 6 (en Windows Server 2003 o Windows Server 2003 R2) pueden generar errores como el siguiente:
System.Web.HttpException: No se encuentra la ruta de acceso '/[raízDeLaAplicación]/eurl.axd/[valor]'.
Este error se produce sólo después de haber habilitado ASP.NET 4 en IIS 6. Se debe a que, cuando ASP.NET detecta que un sitio web está configurado para usar ASP.NET 4, un componente nativo de ASP.NET 4 pasa direcciones URL sin extensión a la parte administrada de ASP.NET para procesarlas.
Sin embargo, si los directorios virtuales bajo un sitio web de ASP.NET 4 están configurados para usar ASP.NET 2.0, el procesamiento de una dirección URL sin extensión de esta forma produce una dirección URL modificada que contiene "eurl.axd" y que se envía a la aplicación de ASP.NET 2.0. ASP.NET 2.0 no reconoce el formato "eurl.axd". Por tanto, ASP.NET 2.0 intenta buscar y ejecutar un archivo denominado "eurl.axd". Puesto que este archivo no existe, la solicitud da error y genera una excepción "HttpException".
Para resolver este problema:
Opción 1
--------
Si no es necesario ASP.NET 4 para ejecutar el sitio web, reasigne el sitio para que use ASP.NET 2.0.
Opción 2
---------
Si ASP.NET 4 es necesario para ejecutar el sitio web, mueva los directorios virtuales secundarios de ASP.NET 2.0 a otro sitio web que esté asignado a ASP.NET 2.0.
Opción 3
---------
Si no es práctico reasignar el sitio web a ASP.NET 2.0 o cambiar la ubicación de un directorio virtual, deshabilite de forma explícita el procesamiento de direcciones URL sin extensión en ASP.NET 4. Use el siguiente procedimiento:
1. En el Registro de Windows, abra el siguiente nodo:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\4.0.<build#>
Nota: <Nº de compilación> es el número de compilación de la versión de lanzamiento de .NET Framework 4.
2. Cree un valor DWORD denominado "EnableExtensionlessUrls".
3. Establezca "EnableExtensionlessUrls" en 0. Esto deshabilita el comportamiento de las direcciones URL sin extensión.
4. Guarde el valor del Registro y cierre el editor del Registro.
5. Ejecute la herramienta de la línea de comandos "iisreset"; dicha herramienta insta a ISS a leer el nuevo valor del Registro.
Nota: si establece "EnableExtensionlessUrls" en 1, se habilita el comportamiento de las direcciones URL sin extensión. Esta es la configuración predeterminada si no se especifica ningún valor.
Las referencias a espacios de nombres y ensamblados que necesitan los proyectos web que usan Entity Framework se han quitado en la versión RTM del archivo Web.config raíz. Como resultado, los sitios web de datos dinámicos que usan EntityDataSource, así como las aplicaciones web que usan Entity Framework y que se crearon con versiones preliminares de ASP.NET 4 producirán errores de compilación.
Para resolver este problema:
Puede insertar las referencias de ensamblado y espacio de nombres que faltan en el archivo Web.config de la aplicación. El ejemplo siguiente muestra los elementos de ensamblado y espacio de nombres que deben insertarse manualmente en el archivo Web.config del nivel de aplicación.
<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>
En determinados órdenes de instalación de .NET Framework 2.0 y 4 en Windows Vista, Windows Server 2008, Windows 7 y Windows Server 2008 R2, las aplicaciones de ASP.NET 4 generan un error NullReferenceException no controlado desde la clase RoleManagerModule. Esto se produce cuando ASP.NET 4 es la única versión de ASP.NET que se registra en IIS 7 o IIS 7.5, y ASP.NET 2.0 no se ha registrado nunca en IIS o se anuló el registro de ASP.NET 2.0 en IIS 7 o IIS 7.5.
En cada escenario, el registro independiente de ASP.NET 4 da lugar a un orden incorrecto en el archivo de configuración para dos módulos HTTP que se usan en aplicaciones en modo integrado.
Para resolver este problema:
Si bien este problema se ha solucionado en la versión de lanzamiento de ASP.NET 4, las versiones preliminares de ASP.NET 4 pueden haber especificado el orden incorrecto para los módulos. Si continúa produciéndose la excepción no controlada en un equipo que se ha actualizado de una versión preliminar de ASP.NET 4 a la versión RTM, siga estos pasos:
1. Abra el archivo applicationHost.config, que se encuentra en la siguiente carpeta:
%windir%\System32\inetsrv\config
2. Busque el elemento siguiente:
<location path="" overrideMode="Allow">
En este elemento está la lista de módulos HTTP para el modo integrado. La información está en el elemento <modules>.
3. Busque el elemento que comienza con la siguiente cadena:
<add name="RoleManager" ...
4. Mueva el elemento que aparece debajo del elemento que comienza con la siguiente cadena:
<add name="DefaultAuthentication"...
5. Guarde el archivo.
Cuando termine, una parte de la definición <modules> debe ser parecida al ejemplo siguiente:
<add name="DefaultAuthentication" type="System.Web.Security.DefaultAuthenticationModule" preCondition="managedHandler" />
<add name="RoleManager" type="System.Web.Security.RoleManagerModule" preCondition="managedHandler" />
Las aplicaciones de formularios Web Forms de MVC 2 y ASP.NET 4 que usan direcciones URL sin extensión pueden devolver errores HTTP 404 cuando se ejecutan en Windows Vista, Windows Server 2008, Windows 7 o Windows Server 2008 R2. Esta situación puede producirse cuando solo está habilitada la opción Extensibilidad de .NET mientras IIS se instala desde el cuadro de diálogo Características de Windows. Una instalación mínima de IIS no incluirá determinados módulos HTTP. Debido al modo en que ASP.NET e IIS administran las transiciones de eventos de canalización HTTP, los módulos HTTP que faltan impiden que el módulo de enrutamiento URL de ASP.NET se ejecute en el momento adecuado. Como resultado, el módulo de enrutamiento URL no procesa las solicitudes de direcciones URL sin extensión y se produce un error 404.
Para resolver este problema:
En el cuadro de diálogo "Activar o desactivar las características de Windows" de la aplicación
"Programas y características" del Panel de control de Windows, siga estos pasos:
1. Navegue hasta el siguiente nodo:
Internet Information Services --> Servicios de World Wide Web --> Características HTTP comunes
2. Asegúrese de que está seleccionada la opción "Redirección HTTP".
O bien
1. Navegue hasta el siguiente nodo:
Internet Information Services --> Servicios de World Wide Web --> Características de rendimiento
2. Asegúrese de que está seleccionada la opción "Compresión de contenido estático".
Una vez seleccionada una de estas opciones, haga clic en "Aceptar" para guardar los cambios.
Al habilitar de nuevo el módulo Redirección HTTP o el módulo Compresión de contenido estático, se garantiza que ASP.NET e IIS sincronizan correctamente los eventos de canalización HTTP. Esto habilita el módulo de enrutamiento URL para procesar direcciones URL sin extensión.
En versiones anteriores de ASP.NET, se incluía una referencia al ensamblado System.Web.Mobile.dll en el archivo Web.config raíz en la sección <assemblies> en <system.web><compilation>. Con el fin de mejorar el rendimiento, se ha quitado la referencia a este ensamblado.
Para resolver este problema:
El ensamblado System.Web.Mobile.dll se incluye en ASP.NET 4, pero está desusado. Si desea usar tipos del ensamblado System.Web.Mobile.dll, agregue una referencia a este ensamblado, en el archivo Web.config raíz o en un archivo Web.config de aplicación. Por ejemplo, si desea usar alguno de los controles móviles de ASP.NET (desusados), debe agregar al archivo Web.config una referencia al ensamblado System.Web.Mobile.dll.
Los archivos de definición de explorador se han actualizado para que contengan información acerca de exploradores y dispositivos nuevos y actualizados. Se han quitado exploradores y dispositivos antiguos como Netscape Navigator y se han agregado exploradores y dispositivos más recientes como Google Chrome y Apple iPhone.
Para resolver este problema:
Puede usar los archivos de definición de explorador antiguos con ASP.NET 4. Estos archivos y la documentación para instalarlos se encuentran en la versión de los archivos de definición de explorador de ASP.NET en http://go.microsoft.com/fwlink/?LinkID=186493.
Las versiones localizadas de los archivos de Microsoft Ajax JavaScript, como MicrosoftAjax.debug.ja.js, no se agregarán a la red de entrega de contenido (CDN) de Microsoft Ajax hasta que se hayan publicado las versiones localizadas de .NET Framework 4. Por tanto, no habilite la propiedad ScriptManager.EnableCdn cuando esté usando una versión localizada de .NET Framework y CDN.
Para resolver este problema:
Espere hasta que se publiquen las versiones localizadas de .NET Framework 4 antes de usar la red de entrega de contenido (CDN) de Microsoft Ajax. Hasta entonces, asegúrese de que los controles ScriptManager de la aplicación no tengan EnableCdn="true".
Después de instalar ASP.NET 4, los contadores de rendimiento de ASP.NET genéricos solo proporcionan información de las aplicaciones de ASP.NET 4. Si se usan los contadores de rendimiento genéricos con aplicaciones de ASP.NET 1.1, ASP.NET 2.0 y ASP.NET 3.5, los contadores no proporcionan ninguna información. Los datos de rendimiento de aplicaciones que ejecutan versiones anteriores de ASP.NET deben usar las categorías de rendimiento de ASP.NET con versión.
Los contadores de rendimiento de ASP.NET genéricos incluyen las siguientes categorías de contadores de rendimiento: "ASP.NET" y "Aplicaciones ASP.NET".
Las categorías de contadores de rendimiento de ASP.NET con versión tienen nombres similares a estos: "ASP.NET v2.0.50727" y "ASP.NET Apps v2.0.50727".
Para resolver este problema:
Este comportamiento es así por diseño. La versión más reciente de ASP.NET instalada en un equipo "es propietaria" de las categorías de contadores de rendimiento genéricos. Por tanto, se recomienda usar las categorías de contadores de rendimiento con versión cuando recopile datos de rendimiento de varias aplicaciones de ASP.NET que ejecuten versiones diferentes de ASP.NET.
No se tiene constancia de ningún problema.
No se tiene constancia de ningún problema.
No se tiene constancia de ningún problema.
No se tiene constancia de ningún problema.
No se tiene constancia de ningún problema.
Después de actualizar .NET Framework 4 de la versión Beta 2 a la versión RTM, puede producirse el siguiente error al iniciar servicios o reiniciar IIS:
"El sistema no puede encontrar el archivo especificado".
Para resolver este problema:
Repare .NET Framework Client Profile en la aplicación Programas del Panel de control.
Los ensamblados de WPF no se instalan ni se admiten en equipos ia64.
Para resolver este problema:
No se puede solucionar. WPF no se puede utilizar en ia64.
Cuando se valida un flujo de trabajo que incluye el operador sizeof, se produce una excepción.
Para resolver este problema:
No use el operador sizeof en flujos de trabajo.
.NET Framework 4 Client Profile no se admite en ia64.
Para resolver este problema:
Si desinstala .NET Framework 4 en ia64, asegúrese de desinstalar la versión completa y la versión Client Profile.
© 2010 Microsoft Corporation. Reservados todos los derechos.
Términos de uso | Marcas comerciales | Declaración de privacidad