Compartir a través de

ASP.NET 4 cambios importantes

En este documento se describen los cambios realizados para la versión 4 de .NET Framework que pueden afectar potencialmente a las aplicaciones que se crearon con versiones anteriores, incluidas las versiones beta 1 y Beta 2 de ASP.NET 4.

Descargar este documento técnico

Contenido

Configuración de controlRenderingCompatibilityVersion en el archivo Web.config
Cambios de ClientIDMode
HtmlEncode y UrlEncode ahora codifican comillas simples
El analizador de páginas de ASP.NET (.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
El algoritmo hash predeterminado ahora está 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 se ejecutan bajo aplicaciones de ASP.NET 2.0 o ASP.NET 3.5
4 sitios web no se inician en equipos donde está instalado SharePoint
La propiedad HttpRequest.FilePath ya no incluye valores pathInfo
ASP.NET 2.0 Aplicaciones podrían generar errores HttpException que hacen referencia a eurl.axd
Es posible que los manejadores de eventos podrían no ser elevados 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 en el espacio de nombres System.Web.Security han sido reubicados
Cambios en la caché de salida que afectan la variabilidad del encabezado HTTP
Las clases de System.Web.Security para Passport están obsoletas
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 de ControlRenderingCompatibilityVersion en el archivo Web.config

Los controles de ASP.NET se han modificado en la versión 4 de .NET Framework para permitir especificar de forma más precisa cómo representan el código de marcado. En versiones anteriores de .NET Framework, algunos controles emitían marcado que no tenía ninguna manera de deshabilitar. De forma predeterminada, ASP.NET 4 ya no genera este tipo de marcado.

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 al archivo que conserva la Web.config representación heredada. Sin embargo, si actualiza una aplicación cambiando el grupo de aplicaciones de IIS para que tenga 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 Web.config archivo:

<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 border="0" atributo.
  • 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 de nombre .
  • El control Table ya no representa un border="0" atributo.
  • Los controles que no están diseñados para la entrada del usuario (por ejemplo, el control Etiqueta ) ya no representan el disabled="disabled" atributo si su propiedad Enabled está establecida en false (o si heredan esta configuración de un control de contenedor).

Cambios de ClientIDMode

El valor ClientIDMode de ASP.NET 4 le permite especificar cómo ASP.NET genera el atributo id para los elementos HTML. En versiones anteriores de ASP.NET, el comportamiento predeterminado era equivalente a la configuración de AutoID de ClientIDMode. Sin embargo, la configuración predeterminada ahora es Predecible.

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 al Web.config archivo que conserva el comportamiento de versiones anteriores de .NET Framework. Sin embargo, si actualiza una aplicación cambiando el grupo de aplicaciones de IIS para que tenga como destino .NET Framework 4, ASP.NET usa el nuevo modo de forma predeterminada. Para deshabilitar el nuevo modo de identificador de cliente, agregue la siguiente configuración en el Web.config archivo:

<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 ASP.NET (.aspx) es más estricto.

El analizador para páginas de ASP.NET (.aspx archivos) y controles de usuario (.ascx archivos) es más estricto en ASP.NET 4 y rechazará más ejemplos de marcado invá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 estilo no cerrado que se extiende hasta el atributo CssClass.

Archivos de definición del explorador actualizados

Los archivos de definición del explorador se han actualizado para incluir información sobre los exploradores y dispositivos nuevos y actualizados. Se han quitado los exploradores y dispositivos más antiguos, como Netscape Navigator, y se han agregado navegadores 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, verá un error. Por ejemplo, si la App_Browsers carpeta 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 expone la propiedad Request.Browser de la página) está controlado por los archivos de definiciones del explorador. Por lo tanto, la información devuelta accediendo 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 correspondiente \CONFIG\Browsers 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 incluyó una referencia al ensamblado System.Web.Mobile.dll en el archivo raíz Web.config de la sección de ensamblados en . Para mejorar el rendimiento, se quitó 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 de aplicación Web.config . Por ejemplo, si desea usar cualquiera de los controles móviles obsoletos de ASP.NET, debe agregar una referencia al ensamblado 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 las páginas ASP.NET (.aspx archivos 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 a las solicitudes de páginas .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 para 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 Web.config archivo:

<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 tienen acceso a entradas HTTP potencialmente no seguras que podrían ser vectores de ataque XSS.

El algoritmo de hash predeterminado ahora es HMACSHA256

ASP.NET usa algoritmos de cifrado y 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 ahora usa el algoritmo HMACSHA256 para las operaciones hash en cookies y estado de vista. Las versiones anteriores de ASP.NET usaron el algoritmo de HMACSHA1 anterior.

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 en todas las versiones de .NET Framework. Para configurar una aplicación web de ASP.NET 4 para usar el algoritmo de HMACSHA1 anterior, agregue el siguiente valor en el Web.config archivo:

<machineKey validation="SHA1" />

Los archivos de configuración raíz (el machine.config archivo 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 encontró en los archivos de aplicación Web.config . Debido a la complejidad de los sistemas de configuración de IIS 7 y IIS 7.5 administrados, la ejecución de aplicaciones ASP.NET 3.5 en ASP.NET 4 y en IIS 7 e IIS 7.5 puede provocar errores de configuración ASP.NET o 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 de Web.config la aplicación ASP.NET 3.5 para que contenga la configuración adecuada para ASP.NET 4.

Sin embargo, es un escenario compatible 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 de Web.config 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 de nivel Web.config de aplicación con los archivos ASP.NET 2.0 machine.config . Debido a esto, los archivos de nivel Web.config 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 de sistema base 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 modificados Web.config 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 de nivel Web.config de aplicación y la definición completa del archivo ASP.NET 4 machine.config . Como resultado, en tiempo de ejecución, el sistema de configuración 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 IIS 7 e IIS 7.5 devuelve un error de configuración porque realiza una comparación de texto en el atributo de tipo definido para un controlador de sección de configuración administrada. Dado que todos los Web.config archivos 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 ASP.NET 4 machine.config 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 configuración en IIS 7 e IIS 7.5.

Resolución de estos problemas

La solución alternativa para el primer escenario es actualizar el archivo de nivel Web.config de aplicación mediante la inclusión del texto de configuración reutilizable de un Web.config archivo 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 grupos de secciones de configuración del archivo a nivel de aplicación Web.config. Estas definiciones suelen estar en la parte superior del archivo de nivel Web.config 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.

ASP.NET 4 aplicaciones secundarias fallan al iniciarse cuando están bajo aplicaciones ASP.NET 2.0 o 3.5

ASP.NET 4 aplicaciones configuradas como elementos secundarios de aplicaciones que ejecutan versiones anteriores de ASP.NET podrían no iniciarse debido a errores de configuración o compilación. En el ejemplo siguiente se muestra una estructura de directorios para una aplicación afectada.

/parentwebapp (configurado para usar ASP.NET 2.0 o ASP.NET 3.5)
/childwebapp (configurado para usar ASP.NET 4)

La aplicación de la childwebapp carpeta 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 childwebapp carpeta también no 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 de la parentwebapp carpeta 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 childwebapp carpeta. Dependiendo de si la aplicación web de ASP.NET 4 se ejecuta en IIS 7 (o IIS 7.5) o en IIS 6, el sistema de configuración de IIS o el sistema de compilación ASP.NET 4 devolverá un error.

Los pasos que debe seguir para resolver este problema y obtener que la aplicación secundaria ASP.NET 4 funcione depende de si la aplicación ASP.NET 4 se ejecuta en IIS 6 o en IIS 7 (o IIS 7.5).

Paso 1 (solo IIS 7 o IIS 7.5)

Este paso solo es necesario en sistemas operativos que ejecutan IIS 7 o IIS 7.5, que incluye Windows Vista, Windows Server 2008, Windows 7 y Windows Server 2008 R2.

Mueva la definición configSections en el Web.config archivo de la aplicación primaria (la aplicación que se ejecuta ASP.NET 2.0 o ASP.NET 3.5) en el archivo raíz Web.config de the.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 de Web.config 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 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 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 de configuración . 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 (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 Web.config archivo de la aplicación web primaria que ejecuta ASP.NET 2 o ASP.NET 3.5, agregue una etiqueta de ubicación que especifique explícitamente (para los sistemas de configuración de 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 envolver todas las secciones de configuración empezando por la sección appSettings y terminando en 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 ASP.NET 4 se iniciarán sin errores.

Los sitios web de ASP.NET 4 no se pueden iniciar en equipos donde está instalado SharePoint.

Los servidores web que ejecutan SharePoint tienen un Web.config archivo 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 Web.config archivo, 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 una versión de SharePoint disponible que sea compatible con ASP.NET. Como resultado, no debe intentar ejecutar un sitio web de ASP.NET 4 como sitio secundario debajo de sitios 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.AppRelativeCurrentExecutionFilePath y 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, imagine el siguiente fragmento de dirección URL:

/testapp/Action.mvc/SomeAction

En versiones anteriores de ASP.NET, las propiedades HttpRequest tienen los siguientes valores:

HttpRequest.FilePath: /testapp/Action.mvc/SomeAction

HttpRequest.PathInfo: (vacío)

En ASP.NET 4, las propiedades HttpRequest tienen en su lugar los siguientes valores:

HttpRequest.FilePath: /testapp/Action.mvc

HttpRequest.PathInfo: SomeAction

Aplicaciones ASP.NET 2.0 podrían generar errores HttpException que hacen referencia a eurl.axd

Después de habilitar ASP.NET 4 en IIS 6, ASP.NET 2.0 aplicaciones que se ejecutan en IIS 6 (en Windows Server 2003 o Windows Server 2003 R2) pueden generar errores como los siguientes:

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 por debajo de un sitio web de ASP.NET 4 están configurados para usar ASP.NET 2.0, el procesamiento de la dirección URL sin extensión de esta manera da como resultado una dirección URL modificada que contiene la cadena "eurl.axd". Esta dirección URL modificada se envía a la aplicación 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 mediante una de las siguientes opciones.

Opción 1

Si ASP.NET 4 no es necesario para operar el sitio web, reasigne el sitio para usar 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 de ASP.NET 2.0 secundarios a otro sitio web asignado a ASP.NET 2.0.

Opción 3

Si no es práctico volver a asignar 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. Use el procedimiento siguiente:

  1. En el Registro de Windows, abra el nodo siguiente:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\4.0.30319.0

  1. Cree un nuevo valor DWORD denominado EnableExtensionlessUrls.
  2. Establezca EnableExtensionlessUrls en 0. Esto deshabilita el comportamiento de URL sin extensión.
  3. Guarde el valor del Registro y cierre el editor del Registro.
  4. 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 IIS 7 o IIS 7.5

ASP.NET 4 incluye modificaciones que cambian cómo se representa el atributo de acción del elemento de formulario HTML 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/, lo que da como resultado una solicitud a http://contoso.com/Default.aspx.

ASP.NET 4 ahora representa el valor del atributo de acción del elemento de formulario HTML 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 para http://contoso.com produciría una solicitud a Default.aspx. En ese documento, la etiqueta de formulario 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, ahora ASP.NET genera la etiqueta de formulario de apertura HTML como en el ejemplo siguiente:

<form action="" />

Esta diferencia en la forma en que se representa el atributo de acción puede provocar cambios sutiles en la forma en que IIS procesa una publicación de formulario y ASP.NET. Cuando el atributo action es una cadena vacía, el objeto DefaultDocumentModule de IIS creará una solicitud secundaria en Default.aspx. En la mayoría de las condiciones, esta solicitud secundaria es transparente para el código de la aplicación y la Default.aspx página se ejecuta normalmente.

Sin embargo, una posible interacción entre el código administrado y el modo integrado de IIS 7 o IIS 7.5 puede hacer que las páginas de .aspx administradas dejen de funcionar correctamente durante la solicitud secundaria. Si se producen las condiciones siguientes, la solicitud secundaria a un Default.aspx documento producirá un error o un comportamiento inesperado:

  1. Se envía una página .aspx al explorador con el atributo de acción del elemento de formulario establecido en "".
  2. El formulario se vuelve a publicar en ASP.NET.
  3. 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 ningún módulo de código nativo que se ejecute en modo integrado de IIS 7 o IIS 7.5.
  4. El objeto DefaultDocumentModule de IIS se ejecuta finalmente y crea una solicitud secundaria al Default.aspx documento. 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.
  5. Cuando se ejecuta la canalización HTTP para la solicitud secundaria, el controlador de archivos .aspx se ejecuta durante la fase de ejecución del controlador.
  6. Dado que no hay ningún cuerpo de entidad, no hay variables de formulario y ningún estado de vista y, por tanto, no hay información disponible para el controlador de páginas de .aspx para determinar qué evento (si existe) se supone que se debe generar. Como resultado, ninguno de los controladores de eventos de postback para la página .aspx afectada se ejecuta.

Puede solucionar este comportamiento 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 para las solicitudes administradas agregando el atributo siguiente 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 no son solicitudes 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, por lo que el cuerpo de la entidad todavía está disponible y se transmite a la petición 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 de .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

ASP.NET 2.0 y, por extensión, las características de ASP.NET que se agregaron en la versión 3.5, use el modelo de seguridad de acceso de código (CAS) de .NET Framework 1.1 y 2.0. Sin embargo, la implementación del CAS en ASP.NET 4 se ha revisado sustancialmente. Como resultado, las aplicaciones ASP.NET de confianza parcial que dependen de código de confianza que se ejecuta en la caché global de ensamblados (GAC) podrían fallar con varias excepciones de seguridad. Las aplicaciones de confianza parcial que dependen de modificaciones exhaustivas en la directiva CAS de la máquina también pueden fallar con excepciones de seguridad.

Puede revertir las aplicaciones de ASP.NET 4 con confianza parcial al comportamiento de ASP.NET 1.1 y 2.0 usando el 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 CAS heredado, se habilitan los siguientes comportamientos de CAS antiguos:

  • Respeta la política CAS de la máquina.
  • 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.

No se puede revertir un escenario en .NET Framework 4: las aplicaciones de confianza parcial no 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 aplicaciones de confianza parcial no Web. A continuación, 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. La llamada a estos tipos desde aplicaciones de confianza parcial no web ya no se admite en .NET Framework 4.

Nota:

La funcionalidad HtmlEncode y HtmlDecode de la clase System.Web.HttpUtility se movió a la nueva clase System.Net.WebUtility de .NET Framework 4. Si esa era la única funcionalidad de ASP.NET que se estaba usando, modifique el código de la aplicación para utilizar la nueva clase WebUtility en su lugar.

A continuación se muestra un resumen general de los cambios realizados en la implementación de CAS predeterminada 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 completa están disponibles en un dominio de aplicación.
  • Los conjuntos de concesión de permisos con confianza parcial de ASP.NET son independientes de cualquier directiva CAS de nivel empresarial, de nivel de máquina o de nivel de usuario.
  • Los ensamblajes de ASP.NET incluidos en 3.5 y 3.5 SP1 se han convertido a usar el modelo de transparencia del .NET Framework 4.
  • Se ha reducido considerablemente el uso del atributo ASP.NET AspNetHostingPermission . 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 ASP.NET proveedores de compilación se han actualizado para marcar explícitamente los ensamblados como transparentes.
  • Todos los ensamblados 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 no web, como ClickOnce, no podrán invocar a ensamblados de ASP.NET.

Para obtener más información sobre el nuevo modelo de seguridad de acceso a código de ASP.NET 4, vea Using Code Access Security in ASP.NET Applications (Uso de seguridad de acceso de código en ASP.NET Aplicaciones ) en el sitio web de MSDN.

MembershipUser y otros tipos del espacio de nombres System.Web.Security han sido trasladados

Algunos tipos que se usan en la membresía de ASP.NET se han movido del ensamblado System.Web.dll al nuevo ensamblado System.Web.ApplicationServices.dll. Los tipos se trasladaron para resolver las dependencias de capas arquitectónicas entre los tipos del cliente y las SKU extendidas del .NET Framework.

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 a los que se hace referencia que usa de forma predeterminada el sistema de compilación de ASP.NET. Si actualiza un proyecto de sitio web que se creó con una versión anterior de ASP.NET a ASP.NET 4 al abrirlo 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 abriendolo 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 movieron a un ensamblado diferente. La información de reenvío de tipos se ha agregado a la versión ASP.NET 4 de System.Web.dll, que enruta automáticamente las referencias de estos tipos en tiempo de ejecución a su nueva ubicación.

Sin embargo, las bibliotecas de clases que usan tipos de pertenencia específicos y que se han actualizado desde versiones anteriores de ASP.NET no se compilará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 agregando una referencia en el proyecto de biblioteca de clases para 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 la caché de resultado para variar el encabezado HTTP

En ASP.NET 1.0, un error provocó que las páginas almacenadas en caché especificadas Location="ServerAndClient" como una configuración de caché de salida emitan un Vary:* encabezado HTTP en la respuesta. Esto tuvo el efecto de indicar a los exploradores cliente que nunca almacenen 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 Vary:* encabezado. Este método se eligió porque el cambio del encabezado HTTP emitido se consideraba un cambio potencialmente importante en el momento. 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 de SetOmitVaryStar existente.

En ASP.NET 4, se tomó la decisión de corregir el problema raíz. El Vary:* encabezado HTTP ya no se emite a partir de respuestas que especifican la siguiente directiva:

<%@OutputCache Location="ServerAndClient" %>

Como resultado, SetOmitVaryStar ya no es necesario para suprimir el Vary:* encabezado.

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 de 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 se ha vuelto obsoleta y no admitida desde hace 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 Menu mediante 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 invertida (). 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 otra parte de este documento.

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 de versiones anteriores de ASP.NET.

En el ejemplo siguiente del marcado de 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 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 de 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 otra parte de este documento.

Aviso de declinación de responsabilidades

Este es un documento preliminar y puede cambiarse sustancialmente antes de la versión comercial final del software descrito en este documento.

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 las cambiantes condiciones del mercado, no debe interpretarse como un compromiso por parte de Microsoft y Microsoft no puede garantizar la precisión de cualquier información presentada después de la fecha de publicación.

Este documento técnico es únicamente para fines informativos. MICROSOFT NO OTORGA NINGUNA GARANTÍA, YA SEA EXPLÍCITA, IMPLÍCITA O ESTATUTARIA, CON RESPECTO A LA INFORMACIÓN CONTENIDA EN ESTE DOCUMENTO.

Cumplir con todas las leyes de copyright aplicables es responsabilidad del usuario. Sin limitar los derechos de autor, ninguna parte de este documento puede reproducirse, almacenarse o introducirse en un sistema de recuperación, ni transmitirse en cualquier forma o por cualquier medio (electrónica, mecánica, fotocopiadora, grabación o de otro modo), o con cualquier fin, sin el permiso expreso por escrito de Microsoft Corporation.

Microsoft puede tener patentes, solicitudes de patentes, marcas comerciales, derechos de autor u otros derechos de propiedad intelectual que abarquen la materia de este documento. Salvo que se indique expresamente en cualquier contrato de licencia por escrito de Microsoft, el suministro de este documento no le concede ninguna licencia para estas patentes, marcas comerciales, derechos de autor u otra propiedad intelectual.

A menos que se indique lo contrario, las empresas de ejemplo, organizaciones, productos, nombres de dominio, direcciones de correo electrónico, logotipos, personas, lugares y eventos descritos en este documento son ficticios, y ninguna asociación con ninguna empresa real, organización, producto, nombre de dominio, dirección de correo electrónico, logotipo, persona, lugar o evento está previsto o debe inferirse.

© 2010 Microsoft Corporation. Todos los derechos reservados.

Microsoft y Windows son marcas comerciales registradas o marcas comerciales de Microsoft Corporation en Estados Unidos o en otros países.

Los nombres de las empresas y productos reales mencionados aquí pueden ser las marcas comerciales de sus respectivos propietarios.

  • Last updated on