Cambios importantes de ASP.NET 4
En este documento se describen los cambios realizados para el lanzamiento de la versión 4 de .NET Framework que pueden afectar potencialmente a las aplicaciones que se crearon mediante versiones anteriores, incluidas las versiones Beta 1 y Beta 2 de ASP.NET 4.
Contenido
Configuración ControlRenderingCompatibilityVersion en el archivo Web.config
Cambios de ClientIDMode
HtmlEncode y UrlEncode ahora codifican comillas simples
El analizador de páginas de ASP.NET Page (.aspx) es más estricto
Archivos de definición del explorador actualizados
System.Web.Mobile.dll quitado del archivo de configuración web raíz
Validación de solicitudes de ASP.NET
El algoritmo hash predeterminado ahora es HMACSHA256
Errores de configuración relacionados con la nueva configuración raíz de ASP.NET 4
Las aplicaciones secundarias de ASP.NET 4 no se inician cuando están bajo aplicaciones ASP.NET 2.0 o ASP.NET 3.5
Los sitios web de ASP.NET 4 no se inician en equipos donde está instalado SharePoint
La propiedad HttpRequest.FilePath ya no incluye valores PathInfo
Las aplicaciones de ASP.NET 2.0 podrían generar errores HttpException que hacen referencia a eurl.axd
Es posible que los controladores de eventos no se generen en un documento predeterminado en el modo integrado de IIS 7 o IIS 7.5
Cambios en la implementación de seguridad de acceso a código (CAS) de ASP.NET
MembershipUser y otros tipos del espacio de nombres System.Web.Security se han movido
Cambios en el almacenamiento en caché de salida para el encabezado HTTP Vary *
Los tipos de System.Web.Security para Passport están obsoletos
La propiedad MenuItem.PopOutImageUrl no puede representar una imagen en ASP.NET 4
Menu.StaticPopOutImageUrl y Menu.DynamicPopOutImageUrl no pueden representar imágenes cuando las rutas de acceso contienen barras diagonales inversas
Declinación de responsabilidades
Configuración ControlRenderingCompatibilityVersion en el archivo Web.config
Los controles ASP.NET se han modificado en la versión 4 de .NET Framework para permitirle especificar de forma más precisa cómo representan el marcado. En versiones anteriores de .NET Framework algunos controles emitían marcado que no tenía ninguna manera de deshabilitar. De forma predeterminada, este tipo de marcado ya no se genera en ASP.NET 4.
Si usa Visual Studio 2010 para actualizar la aplicación desde ASP.NET 2.0 o ASP.NET 3.5, la herramienta agrega automáticamente una configuración en el archivo Web.config que conserva la representación heredada. Sin embargo, si actualiza una aplicación cambiando el grupo de aplicaciones en IIS para elegir como destino .NET Framework 4, ASP.NET usa el nuevo modo de representación de forma predeterminada. Para deshabilitar el nuevo modo de representación, agregue la siguiente configuración en el archivo Web.config:
<pages controlRenderingCompatibilityVersion="3.5" />
Los principales cambios de representación que aporta el nuevo comportamiento son los siguientes:
- Los controles Image e ImageButton ya no representan un atributo
border="0". - La clase BaseValidator y los controles de validación que derivan de ella ya no representan texto rojo de forma predeterminada.
- El control HtmlForm no representa un atributo name.
- El control Table ya no representa un atributo
border="0". - Los controles que no están diseñados para la entrada del usuario (por ejemplo, el control Label) ya no representan el atributo
disabled="disabled"si su propiedad Enabled está establecida en false (o si heredan esta configuración de un control contenedor).
Cambios de ClientIDMode
La configuración ClientIDMode de ASP.NET 4 le permite especificar cómo genera ASP.NET el atributo id para los elementos HTML. En versiones anteriores de ASP.NET, el comportamiento predeterminado era equivalente al valor AutoID de ClientIDMode. Sin embargo, la configuración predeterminada ahora Predictable.
Si usa Visual Studio 2010 para actualizar la aplicación desde ASP.NET 2.0 o ASP.NET 3.5, la herramienta agrega automáticamente una configuración en el archivo Web.config que conserva el comportamiento de versiones anteriores de .NET Framework. Sin embargo, si actualiza una aplicación cambiando el grupo de aplicaciones en IIS para elegir como destino .NET Framework 4, ASP.NET usará el nuevo modo de forma predeterminada. Para deshabilitar el nuevo modo de id. de cliente, agregue la siguiente configuración en el archivo Web.config:
<pages clientIDMode="AutoID" />
HtmlEncode y UrlEncode ahora codifican comillas simples
En ASP.NET 4, los métodos HtmlEncode y UrlEncode de las clases HttpUtility y HttpServerUtility se han actualizado para codificar el carácter de comillas simples (') de la siguiente manera:
- El método HtmlEncode codifica las instancias de la comilla simple como ' .
- El método UrlEncode codifica las instancias de la comilla simple como %27.
El analizador de páginas de ASP.NET Page (.aspx) es más estricto
El analizador de páginas de página ASP.NET (archivos .aspx) y controles de usuario (archivos .ascx) es más estricto en ASP.NET 4 y rechazará más instancias de marcado no válido. Por ejemplo, los dos fragmentos de código siguientes analizarían correctamente en versiones anteriores de ASP.NET, pero ahora generarán errores del analizador en ASP.NET 4.
<asp:HiddenField runat="server" ID="SomeControl" Value="sampleValue" ; />
Observe el punto y coma no válido al final de la etiqueta HiddenField.
<asp:LinkButton runat="server" ID="SomeControl" onclick="someControlClicked"
style="display:inline; CssClass="searchLink" />
Observe el atributo style no cerrado que se ejecuta en el atributo CssClass.
Archivos de definición del explorador actualizados
Los archivos de definición de explorador se han actualizado para que incluyan información sobre exploradores y dispositivos nuevos y actualizados. Se han quitado exploradores y dispositivos anteriores, como Netscape Navigator, y se han agregado exploradores y dispositivos más recientes, como Google Chrome y Apple iPhone.
Si la aplicación contiene definiciones de explorador personalizadas que heredan de una de las definiciones de explorador que se han quitado, aparecerá un error. Por ejemplo, si la carpeta App_Browsers contiene una definición de explorador que hereda de la definición del explorador IE2, recibirá el siguiente mensaje de error de configuración:
- No se encuentra el explorador o el elemento de puerta de enlace con el identificador “IE2”.
Nota:
El objeto HttpBrowserCapabilities (que es expuesto por la propiedad Request.Browser de la página) está controlado por los archivos de definiciones del explorador. Por lo tanto, la información que se devuelve mediante el acceso a una propiedad de este objeto en ASP.NET 4 podría ser diferente de la información devuelta en una versión anterior de ASP.NET.
Puede revertir a los archivos de definición de explorador antiguos copiando los archivos de definición del explorador desde la carpeta siguiente:
Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\Browsers
Copie los archivos en la carpeta \CONFIG\Browsers correspondiente para ASP.NET 4. Después de copiar los archivos, ejecute la herramienta de línea de comandos Aspnet_regbrowsers.exe.
System.Web.Mobile.dll quitado del archivo de configuración web raíz
En versiones anteriores de ASP.NET se incluía una referencia al ensamblado System.Web.Mobile.dll en el archivo raíz Web.config en la sección assemblies de debajo. Para mejorar el rendimiento se ha quitado la referencia a este ensamblado.
El ensamblado System.Web.Mobile.dll se incluye en ASP.NET 4, pero está en desuso. Si desea usar tipos del ensamblado de System.Web.Mobile.dll, agregue una referencia a este ensamblado al archivo raíz Web.config o a un archivo Web.config de aplicación. Por ejemplo, si desea usar cualquiera de los controles ASP.NET para dispositivos móviles (en desuso), debe agregar una referencia al ensamblado de System.Web.Mobile.dll al archivo Web.config.
Validación de solicitudes de ASP.NET
La característica de validación de solicitudes de ASP.NET proporciona un determinado nivel de protección predeterminada frente a ataques de scripting entre sitios (XSS). En versiones anteriores de ASP.NET la validación de solicitudes estaba habilitada de forma predeterminada. Sin embargo, solo se aplicaba a páginas ASP.NET (archivos .aspx y sus archivos de clase) y solo cuando esas páginas se estaban ejecutando.
En ASP.NET 4, de forma predeterminada, la validación de solicitudes está habilitada para todas las solicitudes, ya que está habilitada antes de la fase BeginRequest de una solicitud HTTP. Como resultado, la validación de solicitudes se aplica a las solicitudes de todos los recursos de ASP.NET, no solo solicitudes de página .aspx. Esto incluye solicitudes como llamadas de servicio web y controladores HTTP personalizados. La validación de solicitudes también está activa cuando los módulos HTTP personalizados leen el contenido de una solicitud HTTP.
Como resultado, los errores de validación de solicitudes ahora pueden producirse en las solicitudes que anteriormente no desencadenaban errores. Para revertir al comportamiento de la característica de validación de solicitudes de ASP.NET 2.0, agregue la siguiente configuración en el archivo Web.config:
<httpRuntime requestValidationMode="2.0" />
Sin embargo, se recomienda analizar los errores de validación de solicitudes para determinar si los controladores, módulos u otro código personalizado existentes tienen acceso a entradas HTTP potencialmente no seguras que podrían ser vectores de ataque XSS.
El algoritmo hash predeterminado ahora es HMACSHA256
ASP.NET usa cifrado y algoritmos hash para ayudar a proteger los datos, como las cookies de autenticación de formularios y el estado de vista. De forma predeterminada, ASP.NET 4 usa ahora el algoritmo HMACSHA256 para las operaciones de hash en las cookies y el estado de visualización. Las versiones anteriores de ASP.NET usaban el algoritmo HMACSHA1, más antiguo.
Las aplicaciones pueden verse afectadas si ejecuta entornos mixtos de ASP.NET 2.0/ASP.NET 4 en los que los datos, como las cookies de autenticación de formularios, deben funcionar entre versiones de .NET Framework. Para configurar una aplicación web de ASP.NET 4 para usar el antiguo algoritmo de HMACSHA1, agregue el siguiente valor en el archivo Web.config:
<machineKey validation="SHA1" />
Errores de configuración relacionados con la nueva configuración raíz de ASP.NET 4
Los archivos de configuración raíz (el archivo machine.config y el archivo raíz Web.config) para .NET Framework 4 (y, por tanto, ASP.NET 4) se han actualizado para incluir la mayoría de la información de configuración reutilizable que en ASP.NET 3.5 se encontraba en los archivos de aplicación Web.config. Dada la complejidad de los sistemas de configuración administrados de IIS 7 e IIS 7.5, la ejecución de aplicaciones de ASP.NET 3.5 en ASP.NET 4 y en IIS 7 e IIS 7.5 puede producir errores de configuración en ASP.NET o en IIS.
Se recomienda actualizar las aplicaciones de ASP.NET 3.5 a ASP.NET 4 mediante las herramientas de actualización del proyecto en Visual Studio 2010, si es práctico. Visual Studio 2010 modifica automáticamente el archivo Web.config de la aplicación ASP.NET 3.5 para que contenga la configuración adecuada para ASP.NET 4.
Sin embargo, es un escenario admitido para ejecutar aplicaciones de ASP.NET 3.5 mediante .NET Framework 4 sin volver a compilar. En ese caso, es posible que tenga que modificar manualmente el archivo Web.config de la aplicación antes de ejecutar la aplicación en .NET Framework 4 y en IIS 7 o IIS 7.5.
En las dos secciones siguientes se describen los cambios que puede que necesite realizar para diferentes combinaciones de software.
Windows Vista SP1 o Windows Server 2008 SP1, donde no se instalan ni las revisiones KB958854 ni SP2. En esta configuración, el sistema de configuración de IIS 7 combina incorrectamente 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 posterior deben tener una definición de sección de configuración system.web.extensions (el elemento) para no provocar un error de validación de IIS 7.
Sin embargo, las entradas de archivo de nivel Web.config de aplicación modificadas manualmente que no coinciden con precisión con las definiciones de sección de configuración reutilizable original que se introdujeron con Visual Studio 2008 provocarán errores de configuración de ASP.NET. (Las entradas de configuración predeterminadas generadas por Visual Studio 2008 funcionan correctamente). Un problema común es que los archivos Web.config modificados manualmente dejan fuera los atributos de configuración allowDefinition y requirePermission que se encuentran en varias definiciones de sección de configuración. Esto provoca una discrepancia entre la sección de configuración abreviada en los archivos Web.config de nivel de aplicación y la definición completa del archivo machine.config de ASP.NET 4. Como resultado, 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 se instala la KB958854 de revisión.
En este escenario, el sistema de configuración nativo de IIS 7 e IIS 7.5 devuelve un error de configuración porque realiza una comparación de texto en el atributo type definido para un controlador de sección de configuración administrada. Dado 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 los controladores de sección de configuración system.web.extensions (y relacionados), y dado que el archivo machine.config de ASP.NET 4 tiene "4.0" en el atributo type para los mismos controladores de sección de configuración, las aplicaciones que se generan en Visual Studio 2008 o Visual Studio 2008 SP1 siempre producen un error en la validación de la configuración en IIS 7 e IIS 7.5.
Resolver estos problemas
La solución alternativa para el primer escenario es actualizar el archivo Web.config de nivel de aplicación mediante la inclusión del texto de configuración reutilizable de un archivo Web.config generado automáticamente por Visual Studio 2008.
Una solución alternativa para el primer escenario es instalar Service Pack 2 para Vista o Windows Server 2008 en el equipo para corregir el comportamiento incorrecto de combinación de configuración del sistema de configuración de IIS. Sin embargo, después de realizar cualquiera de estas acciones, es probable que la aplicación encuentre un error de configuración debido al problema descrito para el segundo escenario.
La solución alternativa para el segundo escenario es eliminar o comentar todas las definiciones de sección de configuración system.web.extensions y las definiciones de grupo de secciones de configuración del archivo Web.config de nivel de aplicación. Estas definiciones suelen estar en la parte superior del archivo Web.config de nivel de aplicación y se pueden identificar mediante el elemento configSections y sus elementos secundarios.
En ambos escenarios se recomienda eliminar manualmente la sección system.codedom, aunque esto no es necesario.
Las aplicaciones secundarias de ASP.NET 4 no se inician cuando están bajo aplicaciones ASP.NET 2.0 o ASP.NET 3.5
Las aplicaciones de ASP.NET 4 configuradas como elementos secundarios de aplicaciones que ejecutan versiones anteriores de ASP.NET podrían no iniciarse debido a errores de configuración o de compilación. En el ejemplo siguiente se muestra una estructura de directorios para una aplicación afectada.
/parentwebapp (configurada para usar ASP.NET 2.0 o ASP.NET 3.5)
/childwebapp (configurada para usar ASP.NET 4)
La aplicación de la carpeta childwebapp no se iniciará en IIS 7 o IIS 7.5 y notificará un error de configuración. El texto del error incluirá un mensaje similar al siguiente:
The requested page cannot be accessed because the related configuration data for the page is invalid.The configuration section 'configSections' cannot be read because it is missing a section declaration.
En IIS 6, la aplicación de la carpeta childwebapp tampoco se iniciará, pero notificará un error diferente. Por ejemplo, el texto de error podría indicar lo siguiente:
The value for the 'compilerVersion' attribute in the provider options must be 'v4.0' or later if you are compiling for version 4.0 or later of the .NET Framework. To compile this Web application for version 3.5 or earlier of the .NET Framework, remove the 'targetFramework' attribute from the element of the Web.config file
Estos escenarios se producen porque la información de configuración de la aplicación primaria en la carpeta parentwebapp forma parte de la jerarquía de información de configuración que determina las opciones de configuración combinadas finales que usa la aplicación web secundaria en la carpeta childwebapp. Dependiendo de si la aplicación web de ASP.NET 4 se ejecuta en IIS 7 (o IIS 7.5) o en IIS 6, devolverá un error el sistema de configuración de IIS o el sistema de compilación de ASP.NET 4.
Los pasos que debe seguir para resolver este problema y conseguir que la aplicación secundaria de ASP.NET 4 funcione depende de si la aplicación de ASP.NET 4 se ejecuta en IIS 6 o en IIS 7 (o IIS 7.5).
Paso 1 (solo para IIS 7 o IIS 7.5)
Este paso solo es necesario en sistemas operativos que ejecutan IIS 7 o IIS 7.5, lo que incluye Windows Vista, Windows Server 2008, Windows 7 y Windows Server 2008 R2.
Mueva la definición configSections en el archivo Web.config de la aplicación primaria (la aplicación que ejecuta ASP.NET 2.0 o ASP.NET 3.5) al archivo raíz Web.config de .NET Framework 2.0. El sistema de configuración nativo de IIS 7 e IIS 7.5 examina el elemento configSections cuando combina la jerarquía de archivos de configuración. Al mover la definición configSections del archivo primario Web.config de la aplicación web al archivo raíz Web.config, se oculta eficazmente el elemento del proceso de combinación de configuración que se produce para la aplicación secundaria de ASP.NET 4.
En un sistema operativo de 32 bits o para grupos de aplicaciones de 32 bits, el archivo raíz Web.config de ASP.NET 2.0 y ASP.NET 3.5 se encuentra normalmente en la carpeta siguiente:
C:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG
En un sistema operativo de 64 bits o para grupos de aplicaciones de 64 bits, el archivo raíz Web.config de ASP.NET 2.0 y ASP.NET 3.5 se encuentra normalmente en la carpeta siguiente:
C:\Windows\Microsoft.NET\Framework64\v2.0.50727\CONFIG
Si ejecuta aplicaciones web de 32 bits y 64 bits en un equipo de 64 bits, debe mover el elemento configSections a los archivos raíz Web.config tanto para los sistemas de 32 bits como para los sistemas de 64 bits.
Al colocar el elemento configSections en el archivo raíz Web.config, pegue la sección inmediatamente después del elemento configuration. En el ejemplo siguiente se muestra el aspecto de la parte superior del archivo raíz Web.config cuando haya terminado de mover los elementos.
Nota:
En el ejemplo siguiente, las líneas se han ajustado para mejorar la legibilidad.
<?xml version="1.0" encoding="utf-8"?>
<!-- The root web configuration file -->
<configuration>
<configSections>
<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>
</configSections>
Paso 2 (para todas las versiones de IIS)
Este paso es necesario si la aplicación web secundaria de ASP.NET 4 se ejecuta en IIS 6 o en IIS 7 (o IIS 7.5).
En el archivo Web.config de la aplicación web primaria que ejecuta ASP.NET 2 o ASP.NET 3.5, agregue una etiqueta location que especifique explícitamente (para los sistemas de configuración IIS y ASP.NET) que las entradas de configuración solo se aplican a la aplicación web primaria. En el ejemplo siguiente se muestra la sintaxis del elemento location que se va a agregar:
<location path="" inheritInChildApplications="false" >
<!-- Additional settings -->
</location>
En el ejemplo siguiente se muestra cómo se usa la etiqueta location para ajustar todas las secciones de configuración empezando por la sección appSettings y terminando con la sección system.webServer.
<location path="" inheritInChildApplications="false" >
<appSettings />
<connectionStrings />
<system.web>
<!-- Removed for brevity -->
</system.web>
<system.codedom>
<!-- Removed for brevity -->
</system.codedom>
<system.webServer>
<!-- Removed for brevity -->
</system.webServer>
</location>
Cuando haya completado los pasos 1 y 2, las aplicaciones web secundarias de ASP.NET 4 se iniciarán sin errores.
Los sitios web de ASP.NET 4 no se inician en equipos donde está instalado SharePoint
Los servidores web que ejecutan SharePoint tienen un archivo Web.config que se implementa en la raíz de un sitio web de SharePoint (por ejemplo, c:\inetpub\wwwroot\web.config para el sitio web predeterminado). En este archivo Web.config, SharePoint establece un nivel de confianza parcial personalizado denominado WSS_Minimal.
Si intenta ejecutar un sitio web de ASP.NET 4 que se implementa como elemento secundario de este tipo de sitio web de SharePoint, verá el siguiente error:
Could not find permission set named 'ASP.NET'.
Este error se produce porque la infraestructura de seguridad de acceso a código (CAS) de ASP.NET 4 busca un conjunto de permisos denominado ASP.NET. Sin embargo, el archivo de configuración de confianza parcial al que hace referencia WSS_Minimal no contiene ningún conjunto de permisos con ese nombre.
Actualmente no hay disponible una versión de SharePoint que sea compatible con ASP.NET. Como resultado, no debería intentar ejecutar un sitio web de ASP.NET 4 como un sitio secundario de un sitio web de SharePoint.
La propiedad HttpRequest.FilePath ya no incluye valores PathInfo
Las versiones anteriores de ASP.NET incluían un valor PathInfo en el valor devuelto de varias propiedades relacionadas con la ruta de acceso de archivo, como HttpRequest.FilePath, HttpRequest.AppRelativeCurrentExecutionFilePathy HttpRequest.CurrentExecutionFilePath. ASP.NET 4 ya no incluye el valor PathInfo en los valores devueltos de estas propiedades. En su lugar, la información PathInfo está disponible en HttpRequest.PathInfo. Por ejemplo, veamos el siguiente fragmento de dirección URL:
/testapp/Action.mvc/SomeAction
En versiones anteriores de ASP.NET, las propiedades HttpRequest tienen los valores siguientes:
HttpRequest.FilePath: /testapp/Action.mvc/SomeAction
HttpRequest.PathInfo: (vacío)
En cambio, en ASP.NET 4, las propiedades HttpRequest tienen los siguientes valores:
HttpRequest.FilePath: /testapp/Action.mvc
HttpRequest.PathInfo: SomeAction
Las aplicaciones de ASP.NET 2.0 podrían generar errores HttpException que hacen referencia a eurl.axd
Una vez que se ha habilitado ASP.NET 4 en IIS 6, las aplicaciones de ASP.NET 2.0 que se ejecutan en IIS 6 (en Windows Server 2003 o Windows Server 2003 R2) podrían generar errores como el siguiente:
System.Web.HttpException: Path '/[yourApplicationRoot]/eurl.axd/[Value]' was not found.
Este error se produce porque cuando ASP.NET detecta que un sitio web está configurado para usar ASP.NET 4, un componente nativo de ASP.NET 4 pasa una dirección URL sin extensión a la parte administrada de ASP.NET para su posterior procesamiento. Sin embargo, si los directorios virtuales que están bajo un sitio web de ASP.NET 4 están configurados para usar ASP.NET 2.0, procesar de esta manera la dirección URL sin extensión da como resultado una dirección URL modificada que contiene la cadena "eurl.axd". Esta dirección URL modificada se envía entonces a la aplicación de ASP.NET 2.0. ASP.NET 2.0 no puede reconocer el formato "eurl.axd". Por lo tanto, ASP.NET 2.0 intenta encontrar un archivo denominado eurl.axd y ejecutarlo. Dado que no existe este archivo, se produce un error en la solicitud con una excepción HttpException.
Puede solucionar este problema de forma alternativa mediante una de las siguientes opciones.
Opción 1
Si no se requiere ASP.NET 4 para ejecutar el sitio web, reasigne el sitio de modo que use ASP.NET 2.0 en su lugar.
Opción 2
Si se requiere ASP.NET 4 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 explícitamente el procesamiento de direcciones URL sin extensión en ASP.NET 4. Utilice el siguiente procedimiento:
- En el Registro de Windows, abra el nodo siguiente:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\4.0.30319.0
- Cree un nuevo valor DWORD denominado EnableExtensionlessUrls.
- Establezca EnableExtensionlessUrls en 0. Esto deshabilita el comportamiento de la dirección URL sin extensión.
- Guarde el valor del Registro y cierre el editor del Registro.
- Ejecute la herramienta de línea de comandos iisreset, lo que hace que IIS lea el nuevo valor del Registro.
Nota:
Al establecer EnableExtensionlessUrls en 1, se habilita el comportamiento de la dirección URL sin extensión. Esta es la configuración predeterminada si no se especifica ningún valor.
Es posible que los controladores de eventos no se generen en un documento predeterminado en el modo integrado de IIS 7 o IIS 7.5
ASP.NET 4 incluye modificaciones que cambian cómo se representa el atributo action del elemento HTML form cuando una dirección URL sin extensión se resuelve en un documento predeterminado. Un ejemplo de una dirección URL sin extensión que se resuelve en un documento predeterminado sería http://contoso.com/ dando como resultado una solicitud a http://contoso.com/Default.aspx.
ASP.NET 4 representa el valor de atributo action del elemento HTML form como una cadena vacía cuando se realiza una solicitud a una dirección URL sin extensión que tiene asignado un documento predeterminado. Por ejemplo, en versiones anteriores de ASP.NET una solicitud a http://contoso.com daría como resultado una solicitud a Default.aspx. En ese documento, la etiqueta form de apertura se representaría como en el ejemplo siguiente:
<form action="Default.aspx" />
En ASP.NET 4, una solicitud para http://contoso.com también da como resultado una solicitud a Default.aspx. Sin embargo, ASP.NET ahora representa la etiqueta HTML form de apertura como en el ejemplo siguiente:
<form action="" />
Esta diferencia en la forma en que se representa el atributo action puede provocar cambios sutiles en la forma en que IIS y ASP.NET procesan una publicación de formulario. Cuando el atributo action es una cadena vacía, el objeto DefaultDocumentModule de IIS creará una solicitud secundaria a Default.aspx. En la mayoría de las condiciones esta solicitud secundaria es transparente para el código de la aplicación, y la página Default.aspx se ejecuta con normalidad.
A pesar de ello, una interacción potencial entre el código administrado y el modo integrado de IIS 7 o IIS 7.5 puede hacer que las páginas .aspx administradas dejen de funcionar correctamente durante la solicitud secundaria. Si se dan las condiciones siguientes, la solicitud secundaria a un documento Default.aspx producirá un error o un comportamiento inesperado:
- Se envía una página .aspx al explorador con el atributo action del elemento form establecido en "".
- El formulario se envía de vuelta a ASP.NET.
- Un módulo HTTP administrado lee una parte del cuerpo de la entidad. Por ejemplo, un módulo lee Request.Form o Request.Params. Esto hace que el cuerpo de la entidad de la solicitud POST se lea en la memoria administrada. Como resultado, el cuerpo de la entidad ya no está disponible para los módulos de código nativo que se ejecutan en el modo integrado de IIS 7 o IIS 7.5.
- El objeto DefaultDocumentModule de IIS se ejecuta finalmente y crea una solicitud secundaria al documento
Default.aspx. Sin embargo, dado que un fragmento del código administrado ya ha leído el cuerpo de la entidad, no hay ningún cuerpo de entidad disponible para enviarlo a la solicitud secundaria. - Cuando se ejecuta la canalización HTTP para la solicitud secundaria, el controlador de archivos
.aspxse ejecuta durante la fase de ejecución de controlador. - Dado que no hay ningún cuerpo de entidad, no hay variables de formulario y ningún estado de visualización y, por tanto, no hay información disponible para el controlador de páginas .aspx para determinar qué evento (si existe) se supone que se debe generar. Como resultado, no se ejecuta ninguno de los controladores de eventos postback para la página .aspx afectada.
Puede solucionar este comportamiento de manera alternativa de las siguientes maneras:
Identifique el módulo HTTP que accede al cuerpo de la entidad de la solicitud durante las solicitudes de documento predeterminadas y determine si se puede configurar para ejecutarse solo para solicitudes administradas. En modo integrado para IIS 7 e IIS 7.5, los módulos HTTP solo se pueden marcar para ejecutarse en las solicitudes administradas agregando el siguiente atributo a la entrada system.webServer/modules del módulo:
precondition="managedHandler"Esta configuración deshabilita el módulo para las solicitudes que IIS 7 e IIS 7.5 determinan como solicitudes que no están siendo administradas. Para las solicitudes de documento predeterminadas, la primera solicitud es a una dirección URL sin extensión. Por lo tanto, IIS no ejecuta ningún módulo administrado marcado con una condición previa del controlador administrado durante el procesamiento inicial de solicitudes. Como resultado, los módulos administrados no leerán accidentalmente el cuerpo de la entidad y, por tanto, el cuerpo de la entidad todavía está disponible y se pasa a la solicitud secundaria y al documento predeterminado.
Si los módulos HTTP problemáticos tienen que ejecutarse para todas las solicitudes (para archivos estáticos, para direcciones URL sin extensión que se resuelven en el objeto DefaultDocumentModule, para las solicitudes administradas, etc.), modifique las páginas .aspx afectadas estableciendo explícitamente la propiedad Action del control System.Web.UI.HtmlControls.HtmlForm de la página en una cadena no vacía. Por ejemplo, si el documento predeterminado es
Default.aspx, modifique el código de la página para establecer explícitamente la propiedad Action del control HtmlForm en "Default.aspx".
Cambios en la implementación de seguridad de acceso a código (CAS) de ASP.NET
Las características de ASP.NET 2.0, y por extensión las características ASP.NET que se agregaron en 3.5, usan el modelo de seguridad de acceso del código (CAS) de .NET Framework 1.1 y 2.0. Aun así, la implementación de CAS en ASP.NET 4 se ha mejorado considerablemente. Como resultado, podría producirse un error con varias excepciones de seguridad en las aplicaciones de ASP.NET de confianza parcial que se basan en código de confianza que se ejecuta en la caché global de ensamblados (GAC). También se podrían producir errores con excepciones de seguridad en las aplicaciones de confianza parcial que se basan en modificaciones extensas de la directiva de CAS del equipo.
Puede revertir las aplicaciones de ASP.NET 4 de confianza parcial al comportamiento de ASP.NET 1.1 y 2.0 mediante el uso del nuevo atributo legacyCasModel en el elemento de configuración trust, como se muestra en el ejemplo siguiente:
<trust level= "Medium" legacyCasModel="true" />
Cuando se revierte al modelo de CAS heredado, se habilitan los siguientes comportamientos de CAS antiguos:
- Se respeta la directiva de CAS del equipo.
- Se permiten varios conjuntos de permisos diferentes en un solo dominio de aplicación.
- Las aserciones de permisos explícitas no son necesarias para los ensamblados de la GAC que se invocan cuando solo ASP.NET u otro código de .NET Framework está en la pila.
Hay un escenario que no se puede revertir en .NET Framework 4: las aplicaciones de confianza parcial que no son web ya no pueden llamar a determinadas API en System.Web.dll y System.Web.Extensions.dll. En versiones anteriores de .NET Framework era posible conceder explícitamente permisos AspNetHostingPermission a las aplicaciones de confianza parcial que no son web. Por tanto, estas aplicaciones podrían usar System.Web.HttpUtility, tipos en los espacios de nombres System.Web.ClientServices.* y tipos relacionados con la pertenencia, los roles y los perfiles. Llamar a estos tipos desde aplicaciones de confianza parcial que no son web ya no se admite en .NET Framework 4.
Nota:
Las funcionalidades HtmlEncode y HtmlDecode de la clase System.Web.HttpUtility se movió a la nueva clase System.Net.WebUtility de .NET Framework 4. Si ese era la única funcionalidad de ASP.NET que se estaba usando, modifique el código de la aplicación para usar la nueva clase WebUtility en su lugar.
A continuación se muestra un resumen general de los cambios realizados en la implementación predeterminada de CAS en ASP.NET 4:
- Los dominios de aplicación de ASP.NET ahora son dominios de aplicación homogéneos. Solo los conjuntos de concesión de confianza parcial y confianza total están disponibles en un dominio de aplicación.
- Los conjuntos de concesión de confianza parcial de ASP.NET son independientes de cualquier directiva de CAS de nivel empresarial, de nivel de máquina o de nivel de usuario.
- Los ensamblados de ASP.NET que se incluyen en 3.5 y 3.5 SP1 se han convertido para usar el modelo de transparencia de .NET Framework 4.
- Se ha reducido considerablemente el uso del atributo AspNetHostingPermission de ASP.NET. La mayoría de las instancias de este atributo se han quitado de las API de ASP.NET públicas.
- Los ensamblados compilados dinámicamente creados por proveedores de compilación de ASP.NET se han actualizado para marcar explícitamente los ensamblados como transparentes.
- Todos los ensamblados de ASP.NET ahora están marcados de tal manera que el atributo APTCA solo se respeta en entornos de hospedaje web. Los entornos de hospedaje de confianza parcial que no son web, como ClickOnce, no podrán llamar a los ensamblados de ASP.NET.
Para obtener más información sobre el nuevo modelo de seguridad de acceso del código de ASP.NET 4, vea Uso de seguridad de acceso del código para aplicaciones de ASP.NET 4 en el sitio web de MSDN.
MembershipUser y otros tipos del espacio de nombres System.Web.Security se han movido
Algunos tipos que se usan en la pertenencia de ASP.NET se han movido de System.Web.dll al nuevo ensamblado System.Web.ApplicationServices.dll. Estos tipos se han movido para resolver las dependencias de capas de arquitectura entre los tipos del cliente y de las SKU de .NET Framework extendidas.
Los proyectos de sitio web no tienen problemas como resultado de mover estos tipos, ya que System.Web.ApplicationServices.dll se agregó a la lista de ensamblados referenciados que usa el sistema de compilación de ASP.NET de forma predeterminada. Si actualiza un proyecto de sitio web que se creó con una versión anterior de ASP.NET a ASP.NET 4 abriéndolo en Visual Studio 2010, el proyecto se compilará sin errores.
Del mismo modo, si actualiza un proyecto de aplicación web que se creó en una versión anterior de ASP.NET a ASP.NET 4 abriéndolo en Visual Studio 2010, el proceso de actualización agrega una referencia a System.Web.ApplicationServices.dll al proyecto. Por lo tanto, los proyectos de aplicación web actualizados también se compilarán sin errores.
Los archivos compilados (binarios) creados con versiones anteriores de ASP.NET también se ejecutarán sin errores en ASP.NET 4, aunque los tipos de pertenencia se movieran a un ensamblado diferente. La información de reenvío de tipos se ha agregado a la versión de ASP.NET 4 de System.Web.dll que enruta automáticamente las referencias en tiempo de ejecución de estos tipos a la nueva ubicación de los tipos.
Sin embargo, las bibliotecas de clases que usan tipos de pertenencia específicos y que se han actualizado desde versiones anteriores de ASP.NET producirán un error de compilación cuando se usen en un proyecto de ASP.NET 4. Por ejemplo, un proyecto de biblioteca de clases podría no compilarse e informar de un error como el siguiente:
The type 'System.Web.Security.MembershipUser' is defined in an assembly that is not referenced. You must add a reference to assembly 'System.Web.ApplicationServices, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'.The type name 'MembershipUser' could not be found. This type has been forwarded to assembly 'System.Web.ApplicationServices, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. Consider adding a reference to that assembly.
Puede solucionar este problema de forma alternativa agregando una referencia en el proyecto de biblioteca de clases a System.Web.ApplicationServices.dll.
En la lista siguiente se muestran los tipos System.Web.Security que se han movido de System.Web.dll a System.Web.ApplicationServices.dll:
- System.Web.Security.MembershipCreateStatus
- System.Web.Security.Membership.CreateUserException
- System.Web.Security.MembershipPasswordException
- System.Web.Security.MembershipPasswordFormat
- System.Web.Security.MembershipProvider
- System.Web.Security.MembershipProviderCollection
- System.Web.Security.MembershipUser
- System.Web.Security.MembershipUserCollection
- System.Web.Security.MembershipValidatePasswordEventHandler
- System.Web.Security.ValidatePasswordEventArgs
- System.Web.Security.RoleProvider
- System.Web.Configuration.MembershipPasswordCompatibilityMode
Cambios en el almacenamiento en caché de salida para el encabezado HTTP Vary *
En ASP.NET 1.0, un error hacía que las páginas en caché que especificaban Location="ServerAndClient" como valor de la caché de salida emitiesen un encabezado HTTP Vary:* en la respuesta. Como consecuencia, se indicaba a los exploradores de cliente que nunca almacenasen en caché la página localmente.
En ASP.NET 1.1 se agregó el método System.Web.HttpCachePolicy.SetOmitVaryStar, al que podría llamar para suprimir el encabezado Vary:*. Este método se eligió porque en ese momento cambiar el encabezado HTTP emitido se consideraba un cambio potencialmente importante. Sin embargo, los desarrolladores han sido confundidos por el comportamiento en ASP.NET, y los informes de errores sugieren que los desarrolladores no conocen el comportamiento SetOmitVaryStarexistente.
En ASP.NET 4 se tomó la decisión de corregir el problema raíz. En ASP.NET 4 ya no se emite el encabezado HTTP Vary:* desde las respuestas que especifican la directiva siguiente:
<%@OutputCache Location="ServerAndClient" %>
Como resultado, SetOmitVaryStar ya no es necesario para suprimir el encabezado Vary:*.
En las aplicaciones que especifican Location="ServerAndClient" en la directiva @ OutputCache de una página, ahora verá el comportamiento implícito por el nombre del valor del atributo Location, es decir, las páginas se almacenarán en caché en el explorador sin necesidad de llamar al método SetOmitVaryStar.
Si las páginas de la aplicación deben emitir Vary:*, llame al método AppendHeader, como en el ejemplo siguiente:
HttpResponse.AppendHeader("Vary","*");
Como alternativa, puede cambiar el valor del atributo Location del almacenamiento en caché de salida a "Server".
Los tipos de System.Web.Security para Passport están obsoletos
La compatibilidad de Passport integrada en ASP.NET 2.0 ha quedado obsoleta y no admitida durante unos años debido a cambios en Passport (ahora LiveID). Como resultado, los cinco tipos relacionados con Passport en System.Web.Security ahora se marcan con el atributo ObsoleteAttribute.
La propiedad MenuItem.PopOutImageUrl no puede representar una imagen en ASP.NET 4
En ASP.NET 3.5, la propiedad MenuItem.PopOutImageUrl le permite especificar la dirección URL de una imagen que se muestra en un elemento de menú para indicar que el elemento de menú tiene un submenú dinámico. En el ejemplo siguiente se muestra cómo especificar esta propiedad en el marcado en ASP.NET 3.5.
<asp:menu id="NavigationMenu"
staticdisplaylevels="1"
staticsubmenuindent="10"
orientation="Vertical"
target="_blank"
runat="server">
<items>
<asp:menuitem navigateurl="default2.aspx"
text="Home"
PopOutImageUrl="~/Images/Popout.gif"
tooltip="Home">
<asp:menuitem navigateurl="default3.aspx"
text="Movies"
PopOutImageUrl="~/Images/Popout.gif"
tooltip="Movies">
</asp:menuitem>
</asp:menuitem>
</items>
</asp:menu>
Como resultado de un cambio de diseño en ASP.NET 4, no se representa ninguna salida para PopOutImageUrl si la propiedad está establecida para la clase MenuItem. En su lugar, debe especificar una dirección URL de imagen directamente en el control Menumediante la propiedad StaticPopOutImageUrl o la propiedad DynamicPopOutImageUrl. Cuando se trabaja con un menú estático, la propiedad Menu.StaticPopOutImageUrl especifica la dirección URL de una imagen que se muestra para indicar que el elemento de menú estático tiene un submenú, como se muestra en el ejemplo siguiente:
<asp:menu id="NavigationMenu"
staticdisplaylevels="1"
staticsubmenuindent="10"
orientation="Vertical"
target="_blank"
StaticPopOutImageTextFormatString="More..."
StaticPopOutImageUrl="Images/Popout.gif"
runat="server">
<items>
<asp:menuitem navigateurl="default2.aspx"
text="Home"
tooltip="Home">
<asp:menuitem navigateurl="default3.aspx"
text="Movies"
tooltip="Movies">
</asp:menuitem>
</asp:menuitem>
</items>
</asp:menu>
Si está trabajando con un menú dinámico, usa la propiedad Menu.DynamicPopOutImageUrl para especificar la dirección URL de una imagen que indica que un elemento de menú dinámico tiene un submenú. El ejemplo siguiente es similar al anterior, pero muestra cómo establecer la propiedad DynamicPopOutImageUrl para un menú dinámico.
<asp:menu id="NavigationMenu"
staticdisplaylevels="1"
staticsubmenuindent="10"
orientation="Vertical"
target="_blank"
DynamicPopOutImageTextFormatString="More..."
DynamicPopOutImageUrl="Images/Popout.gif"
runat="server">
<items>
<asp:menuitem navigateurl="default2.aspx"
text="Home"
tooltip="Home">
<asp:menuitem navigateurl="default3.aspx"
text="Movies"
tooltip="Movies">
</asp:menuitem>
</asp:menuitem>
</items>
</asp:menu>
Si no se establece la propiedad Menu.DynamicPopOutImageUrl y la propiedad Menu.DynamicEnableDefaultPopOutImage se establece en false, no se muestra ninguna imagen. Del mismo modo, si no se establece la propiedad StaticPopOutImageUrl y la propiedad StaticEnableDefaultPopOutImage se establece en false, no se muestra ninguna imagen.
Al establecer las rutas de acceso para estas propiedades, use una barra diagonal (/) en lugar de una barra diagonal inversa (\). Para obtener más información, vea Menu.StaticPopOutImageUrl y Menu.DynamicPopOutImageUrl no pueden representar imágenes cuando las rutas de acceso contienen barras diagonales inversas en otro lugar de este documento.
Menu.StaticPopOutImageUrl y Menu.DynamicPopOutImageUrl no pueden representar imágenes cuando las rutas de acceso contienen barras diagonales inversas
En ASP.NET 4, las imágenes que especifique con las propiedades Menu.StaticPopOutImageUrl y Menu.DynamicPopOutImageUrl no se representarán si la ruta de acceso contiene barras diagonales inversas (\). Se trata de un cambio respecto a versiones anteriores de ASP.NET.
En el ejemplo siguiente del marcado del control Menu se muestra la propiedad StaticPopOutImageUrl establecida mediante una ruta de acceso que contiene una barra diagonal inversa. En ASP.NET 4, la imagen especificada en la propiedad no se representará.
<asp:menu id="NavigationMenu"
staticdisplaylevels="1"
staticsubmenuindent="10"
orientation="Vertical
target="_blank"
StaticPopOutImageTextFormatString="More..."
StaticPopOutImageUrl="Images\Popout.gif"
runat="server">
<items>
<asp:menuitem navigateurl="default2.aspx"
text="Home"
tooltip="Home">
<asp:menuitem navigateurl="default3.aspx"
text="Movies"
tooltip="Movies">
</asp:menuitem>
</asp:menuitem>
</items>
</asp:menu>
Para corregir este problema, cambie los valores de la ruta de acceso especificados en las propiedades StaticPopOutImageUrl y DynamicPopOutImageUrl para usar barras diagonales (/). En el ejemplo siguiente se muestra este cambio:
<asp:menu id="NavigationMenu"
staticdisplaylevels="1"
staticsubmenuindent="10"
orientation="Vertical
target="_blank"
StaticPopOutImageTextFormatString="More..."
StaticPopOutImageUrl="Images/Popout.gif"
runat="server">
<items>
<asp:menuitem navigateurl="default2.aspx"
text="Home"
tooltip="Home">
<asp:menuitem navigateurl="default3.aspx"
text="Movies"
tooltip="Movies">
</asp:menuitem>
</asp:menuitem>
</items>
</asp:menu>
Tenga en cuenta que las aplicaciones que se migraron desde versiones anteriores de ASP.NET a ASP.NET 4 también podrían verse afectadas, ya que se ha cambiado la propiedad MenuItem.PopOutImageUrl. Para obtener más información, vea La propiedad MenuItem.PopOutImageUrl no puede representar una imagen en ASP.NET 4 en otro lugar de este documento.
Declinación de responsabilidades
Este documento es preliminar y puede cambiar considerablemente antes de la versión comercial final del software que se describe en él.
La información contenida en este documento representa la visión actual de Microsoft Corporation sobre los asuntos tratados a fecha de su publicación. Dado que Microsoft debe responder a condiciones de mercado variables, no debe interpretarse como un compromiso por parte de Microsoft, y Microsoft no puede garantizar la precisión de la información presentada tras la fecha de publicación.
Estas notas del producto solo tienen fines informativos. MICROSOFT NO OTORGA NINGUNA GARANTÍA, EXPRESA, IMPLÍCITA O ESTUTARIAS, EN LA INFORMACIÓN DE ESTE DOCUMENTO.
Es responsabilidad del usuario el cumplimiento de todas las leyes de propiedad intelectual aplicables. Sin perjuicio de los derechos que conforman la legislación de propiedad intelectual, ninguna parte de este documento se puede reproducir, almacenar o incorporar en un sistema de recuperación, ni se puede transmitir de forma alguna o por ningún medio (electrónico, mecánico, fotocopia, grabación o de otro modo) ni para ningún propósito, sin el expreso permiso por escrito de Microsoft Corporation.
Microsoft puede ser titular de patentes, solicitudes de patentes, marcas, derechos de autor y otros derechos de propiedad intelectual sobre los contenidos de este documento. El suministro de este documento no le otorga ninguna licencia sobre estas patentes, marcas, derechos de autor u otros derechos de propiedad intelectual, a menos que ello se prevea en un contrato por escrito de licencia de Microsoft.
A menos que se indique lo contrario, los ejemplos de nombres de compañías, organizaciones, productos, nombres de dominio, direcciones de correo electrónico, logotipos, personas, lugares y eventos aquí mencionados son ficticios, y no se pretende ni se debe deducir asociación alguna con compañías, organizaciones, productos, nombres de dominio, direcciones de correo electrónico, logotipos, personas, lugares o eventos reales.
© 2010 Microsoft Corporation. Todos los derechos reservados.
Microsoft y Windows son marcas registradas o marcas comerciales de Microsoft Corporation en Estados Unidos y en otros países.
Los nombres de las compañías y productos reales mencionados en el presente documento pueden ser marcas comerciales de sus respectivos propietarios.
Comentarios
Próximamente: A lo largo de 2024 iremos eliminando gradualmente GitHub Issues como mecanismo de comentarios sobre el contenido y lo sustituiremos por un nuevo sistema de comentarios. Para más información, vea: https://aka.ms/ContentUserFeedback.
Enviar y ver comentarios de