Configuración avanzada del módulo de ASP.NET Core e IIS

En este artículo se describen las opciones de configuración y los escenarios avanzados para el módulo de ASP.NET Core e IIS.

Modificación del tamaño de la pila

Solo se aplica cuando se usa el modelo de hospedaje dentro de proceso.

Configure el tamaño de la pila administrada mediante el valor stackSize en bytes en el archivo web.config. El tamaño predeterminado es de 1 048 576 bytes (1 MB). En el ejemplo siguiente, se cambia el tamaño de la pila a 2 MB (2 097 152 bytes):

<aspNetCore processPath="dotnet"
    arguments=".\MyApp.dll"
    stdoutLogEnabled="false"
    stdoutLogFile="\\?\%home%\LogFiles\stdout"
    hostingModel="inprocess">
  <handlerSettings>
    <handlerSetting name="stackSize" value="2097152" />
  </handlerSettings>
</aspNetCore>

No permitir la rotación en la configuración

La configuración disallowRotationOnConfigChange está pensada para escenarios azules o verdes en los que un cambio en la configuración global no debería hacer que todos los sitios se reciclaran. Cuando esta marca tenga el valor true, solo los cambios que afecten al propio sitio harán que se recicle. Por ejemplo, un sitio se recicla si web.config cambia o bien cambia algo relevante para la ruta de acceso del sitio desde el punto de vista de IIS. Sin embargo, un cambio general en applicationHost.config no provocaría que una aplicación se reciclase. En el ejemplo siguiente se establece este valor en true:

<aspNetCore processPath="dotnet"
    arguments=".\MyApp.dll"
    stdoutLogEnabled="false"
    stdoutLogFile="\\?\%home%\LogFiles\stdout"
    hostingModel="inprocess">
  <handlerSettings>
    <handlerSetting name="disallowRotationOnConfigChange" value="true" />
  </handlerSettings>
</aspNetCore>

Esta configuración corresponde a la API ApplicationPoolRecycling.DisallowRotationOnConfigChange

La configuración de proxy usa el protocolo HTTP y un token de emparejamiento

Solo se aplica al hospedaje fuera de proceso.

El proxy creado entre el módulo ASP.NET Core y Kestrel usa el protocolo HTTP. No hay ningún riesgo de interceptación del tráfico entre el módulo y Kestrel desde una ubicación fuera del servidor.

Un token de emparejamiento sirve para garantizar que las solicitudes recibidas por Kestrel se redirigieron mediante proxy por IIS y no procedieron de otra fuente. El módulo crea el token de emparejamiento y lo establece en una variable de entorno (ASPNETCORE_TOKEN). El token de emparejamiento también se establece en un encabezado (MS-ASPNETCORE-TOKEN) en cada solicitud redirigida mediante proxy. El middleware de IIS comprueba cada solicitud recibida para confirmar que el valor del encabezado del token de emparejamiento coincida con el valor de la variable de entorno. Si los valores del token no coinciden, la solicitud se registra y se rechaza. No se puede acceder a la variable de entorno del token de emparejamiento y al tráfico entre el módulo y Kestrel desde una ubicación fuera del servidor. Sin conocer el valor del token de emparejamiento, un atacante no puede enviar solicitudes que omitan la comprobación en el middleware de IIS.

El módulo ASP.NET Core con una configuración compartida de IIS

El instalador del módulo ASP.NET Core se ejecuta con los privilegios de la cuenta TrustedInstaller. Como la cuenta local del sistema no tiene permiso de modificación en la ruta de acceso de recurso compartido que se usa en la configuración compartida de IIS, el instalador inicia un error de acceso denegado al intentar configurar los valores del módulo en el archivo applicationHost.config del recurso compartido.

Cuando se usa una configuración compartida de IIS en el mismo equipo que la instalación de IIS, ejecute el instalador del lote de hospedaje de ASP.NET Core con el parámetro OPT_NO_SHARED_CONFIG_CHECK establecido en 1:

dotnet-hosting-{VERSION}.exe OPT_NO_SHARED_CONFIG_CHECK=1

Cuando la ruta de acceso a la configuración compartida no se encuentra en el mismo equipo que la instalación de IIS, siga estos pasos:

1. Deshabilite la configuración compartida de IIS.
2. Ejecute el instalador.
3. Exporte el archivo applicationHost.config actualizado en el recurso compartido de archivos.
4. Vuelva a habilitar la configuración compartida de IIS.

Protección de datos

La pila de protección de datos de ASP.NET Core la usan varios middlewares de ASP.NET Core, incluidos los que se emplean en la autenticación. Aunque el código de usuario no llame a las API de protección de datos, la protección de datos se debe configurar con un script de implementación o en el código de usuario para crear un almacén de claves criptográficas persistente. Si no se configura la protección de datos, las claves se conservan en memoria y se descartan cuando se reinicia la aplicación.

Si el conjunto de claves de protección de datos se almacena en memoria cuando se reinicia la aplicación:

• Todos los tokens de autenticación basados en cookie se invalidan.
• Los usuarios tienen que iniciar sesión de nuevo en la siguiente solicitud.
• Ya no se pueden descifrar los datos protegidos con el conjunto de claves. Esto puede incluir tokens CSRF y cookies de TempData de ASP.NET Core MVC.

Para configurar la protección de datos en IIS para conservar el conjunto de claves, use uno de los enfoques siguientes:

• Creación de claves del Registro de protección de datos

  Las claves de protección de datos que las aplicaciones de ASP.NET Core usan se almacenan en el registro externo a las aplicaciones. Para conservar las claves de una determinada aplicación, cree claves del Registro para el grupo de aplicaciones.

  En las instalaciones independientes de IIS que no son de granja de servidores web, puede usar el script de PowerShell Provision-AutoGenKeys.ps1 de protección de datos para cada grupo de aplicaciones usado con una aplicación de ASP.NET Core. Este script crea una clave del Registro en el registro HKLM que solo es accesible para la cuenta de proceso de trabajo del grupo de aplicaciones de la aplicación. Las claves se cifran en reposo mediante DPAPI con una clave de equipo.

  En escenarios de granja de servidores web, una aplicación puede configurarse para usar una ruta de acceso UNC con el fin de almacenar su conjunto de claves de protección de datos. De forma predeterminada, las claves no se cifran. Asegúrese de que los permisos de archivo de un recurso compartido de red se limitan a la cuenta de Windows en la que se ejecuta la aplicación. Puede usar un certificado X509 para proteger las claves en reposo. Considere un mecanismo que permita a los usuarios cargar certificados. coloque los certificados en el almacén de certificados de confianza del usuario y asegúrese de que están disponibles en todos los equipos en los que se ejecuta la aplicación del usuario. Para más información, vea Configurar la protección de datos en ASP.NET Core.

• Configurar el grupo de aplicaciones de IIS para cargar el perfil de usuario

  Esta opción está en la sección Modelo de proceso, en la Configuración avanzada del grupo de aplicaciones. Establezca Cargar perfil de usuario en True. Cuando se establece en True, las claves se almacenan en el directorio del perfil de usuario y se protegen mediante DPAPI con una clave específica de la cuenta de usuario. Las claves se conservan en la carpeta %LOCALAPPDATA%/ASP.NET/DataProtection-Keys.

  También se debe habilitar el atributo setProfileEnvironment del grupo de aplicaciones. El valor predeterminado de setProfileEnvironment es true. En algunos escenarios (por ejemplo, SO Windows), setProfileEnvironment está establecido en false. Si las claves no se almacenan en el directorio del perfil de usuario como se esperaba:

  1. Vaya a la carpeta %windir%/system32/inetsrv/config.
  2. Abra el archivo applicationHost.config .
  3. Busque el elemento <system.applicationHost><applicationPools><applicationPoolDefaults><processModel> .
  4. Confirme que el atributo setProfileEnvironment no está presente, que adopta de forma predeterminada el valor true, o establezca explícitamente el valor del atributo en true.

• Usar el sistema de archivos como un almacén de conjunto de claves

  Ajuste el código de la aplicación para usar el sistema de archivos como un almacén de conjunto de claves. Use un certificado X509 para proteger el conjunto de claves y asegúrese de que sea un certificado de confianza. Si es un certificado autofirmado, colóquelo en el almacén raíz de confianza.

  Cuando se usa IIS en una granja de servidores web:

  • Use un recurso compartido de archivos al que puedan acceder todos los equipos.
  • Implemente un certificado X509 en cada equipo. Configure la protección de datos en el código.

• Establecimiento de una directiva a nivel de equipo para la protección de datos

  El sistema de protección de datos tiene compatibilidad limitada con el establecimiento de una directiva a nivel de equipo predeterminada para todas las aplicaciones que usan las API de protección de datos. Para más información, vea Información general sobre la protección de datos de ASP.NET Core.

Configuración de IIS

Sistemas operativos de servidor Windows

Habilite el rol de servidor Servidor web (IIS) y establezca los servicios de rol.

1. Use el asistente Agregar roles y características del menú Administrar o el vínculo de Administrador del servidor. En el paso Roles de servidor, active la casilla de Servidor web (IIS) .

   

2. Después del paso Características, el paso Servicios de rol se carga para el servidor Web (IIS). Seleccione los servicios de rol IIS que quiera o acepte los servicios de rol predeterminados proporcionados.

   

   Autenticación de Windows (opcional)
   Para habilitar Autenticación de Windows, expanda los nodos siguientes: Servidor web>Seguridad. Seleccione la característica Autenticación de Windows. Para más información, consulte Autenticación de Windows <windowsAuthentication> y Configuración de la autenticación de Windows.

   WebSockets (opcional)
   WebSockets es compatible con ASP.NET Core 1.1 o posterior. Para habilitar WebSockets, expanda los nodos siguientes: Servidor web>Desarrollo de aplicaciones. Seleccione la característica Protocolo WebSocket. Para más información, vea WebSockets.

3. Continúe con el paso Confirmación para instalar el rol y los servicios de servidor web. No es necesario reiniciar el servidor ni IIS después de instalar el rol Servidor web (IIS) .

Sistemas operativos de escritorio Windows

Habilite Consola de administración de IIS y Servicios World Wide Web.

1. Vaya a Panel de control>Programas>Programas y características>Activar o desactivar las características de Windows (lado izquierdo de la pantalla).

2. Abra el nodo Internet Information Services. Abra el nodo Herramientas de administración web.

3. Active la casilla de Consola de administración de IIS.

4. Active la casilla de Servicios World Wide Web.

5. Acepte las características predeterminadas de Servicios World Wide Web o personalice las características de IIS.

   Autenticación de Windows (opcional)
   Para habilitar Autenticación de Windows, expanda los nodos siguientes: Servicios World Wide Web>Seguridad. Seleccione la característica Autenticación de Windows. Para más información, consulte Autenticación de Windows <windowsAuthentication> y Configuración de la autenticación de Windows.

   WebSockets (opcional)
   WebSockets es compatible con ASP.NET Core 1.1 o posterior. Para habilitar WebSockets, expanda los nodos siguientes: Servicios World Wide Web>Características de desarrollo de aplicaciones. Seleccione la característica Protocolo WebSocket. Para más información, vea WebSockets.

6. Si la instalación de IIS requiere un reinicio, reinicie el sistema.

Directorios virtuales

Los directorios virtuales de IIS no son compatibles con aplicaciones ASP.NET Core. Una aplicación puede hospedarse como subaplicación.

Subaplicaciones

Se puede hospedar una aplicación ASP.NET Core como una subaplicación IIS. La ruta de acceso de la subaplicación se convierte en parte de la dirección URL de la aplicación raíz.

Los vínculos a los recursos estáticos dentro de la aplicación secundaria deben usar una notación de tilde con barra diagonal (~/) en las páginas de Razor y MVC. La notación de tilde barra diagonal desencadena un asistente de etiquetas para anteponer la ruta de acceso de la aplicación secundaria al vínculo relativo representado. Para una aplicación secundaria en /subapp_path, una imagen vinculada con src="~/image.png" se representa como src="/subapp_path/image.png". El middleware de archivos estáticos de la aplicación raíz no procesa la solicitud de archivo estático. La solicitud se procesa mediante el middleware de archivos estáticos de la aplicación secundaria.

Nota:

Los componentes Razor (.razor) no deben usar la notación de tilde con barra diagonal. Para obtener más información, consulte la documentación sobre la ruta de acceso base de la aplicación Blazor.

Si el atributo src de un recurso estático se establece en una ruta de acceso absoluta (por ejemplo, src="/image.png"), el vínculo se representa sin la base de la ruta de acceso de la aplicación secundaria. El middleware de archivos estáticos de la aplicación raíz intenta atender al recurso desde el web root, lo que resulta en una respuesta 404 - No encontrado a menos que el recurso estático esté disponible desde la aplicación raíz.

Para hospedar una aplicación ASP.NET Core como aplicación secundaria en otra aplicación ASP.NET Core:

1. Establezca un grupo de aplicaciones para la aplicación secundaria. Establezca Versión de .NET CLR en Sin código administrado porque Core Common Language Runtime (CoreCLR) para .NET Core se arranca para hospedar la aplicación en el proceso de trabajo, no el CLR de escritorio (.NET CLR).

2. Agregue el sitio raíz en el Administrador de IIS con la aplicación secundaria en una carpeta en el sitio raíz.

3. Haga clic con el botón derecho en la carpeta de la aplicación secundaria en el Administrador de IIS y seleccione Convertir en aplicación.

4. En el cuadro de diálogo Agregar aplicación, use el botón Seleccionar en Grupo de aplicaciones para asignar el grupo de aplicaciones que ha creado para la aplicación secundaria. Seleccione Aceptar.

La asignación de un grupo de aplicaciones independiente de la aplicación secundaria es un requisito cuando se utiliza el modelo de hospedaje en proceso.

Para más información sobre el modelo de hospedaje en proceso y cómo configurar el módulo ASP.NET Core, vea Módulo ASP.NET Core (ANCM) para IIS.

Grupos de aplicaciones

El aislamiento de los grupos de aplicaciones se determinan mediante el modelo de hospedaje:

• Hospedaje dentro de proceso: es necesario que las aplicaciones se ejecuten en grupos de aplicaciones distintos.
• Hospedaje fuera de proceso: nuestra recomendación es aislar las aplicaciones entre sí ejecutándolas en su propio grupo de aplicaciones.

El valor predeterminado del cuadro de diálogo Agregar sitio web de IIS es un único grupo de aplicaciones por aplicación. Cuando se proporciona el Nombre del sitio, el texto se transfiere automáticamente al cuadro de texto Grupo de aplicaciones. Al agregar el sitio se crea un grupo de aplicaciones con el nombre del sitio.

Identity del grupo de aplicaciones

Una cuenta de identidad del grupo de aplicaciones permite ejecutar una aplicación en una cuenta única sin tener que crear ni administrar dominios o cuentas locales. En IIS 8.0 o versiones posteriores, el proceso de trabajo de administración de IIS (WAS) crea una cuenta virtual con el nombre del nuevo grupo de aplicaciones y ejecuta los procesos de trabajo del grupo de aplicaciones en esta cuenta de forma predeterminada. En la Consola de administración de IIS, en la opción Configuración avanzada del grupo de aplicaciones, asegúrese de que Identity esté establecido para usar ApplicationPoolIdentity:

El proceso de administración de IIS crea un identificador seguro con el nombre del grupo de aplicaciones en el sistema de seguridad de Windows. Los recursos se pueden proteger mediante esta identidad. Sin embargo, no es una cuenta de usuario real ni se muestra en la consola de administración de usuario de Windows.

Si el proceso de trabajo de IIS requiere acceso con privilegios elevados a la aplicación, modifique la lista de control de acceso (ACL) del directorio que contiene la aplicación:

1. Abra el Explorador de Windows y vaya al directorio.

2. Haga clic con el botón derecho en el directorio y seleccione Propiedades.

3. En la pestaña Seguridad, haga clic en el botón Editar y en el botón Agregar.

4. Haga clic en el botón Ubicaciones y asegúrese de seleccionar el sistema.

5. Escriba el formato IIS AppPool\{APP POOL NAME}, donde el marcador de posición {APP POOL NAME} es el nombre del grupo de aplicaciones, en la sección IIS AppPool\{APP POOL NAME}. Haga clic en el botón Comprobar nombres. Para DefaultAppPool compruebe los nombres con IIS AppPool\DefaultAppPool. Cuando el botón Comprobar nombres está seleccionado, un valor de DefaultAppPool se indica en el área de los nombres de objeto. No es posible escribir el nombre del grupo de aplicaciones directamente en el área de los nombres de objeto. Use el formato IIS AppPool\{APP POOL NAME}, donde el marcador de posición {APP POOL NAME} es el nombre del grupo de aplicaciones, al comprobar el nombre del objeto.

   

6. Seleccione Aceptar.

   

7. Los permisos de lectura y ejecución se deben conceder de manera predeterminada. Proporcione permisos adicionales según sea necesario.

El acceso también se puede conceder mediante un símbolo del sistema con la herramienta ICACLS. Con DefaultAppPool como ejemplo, se usa el comando siguiente para conceder permisos de lectura y ejecución a la carpeta, subcarpetas y archivos de MyWebApp:

ICACLS C:\sites\MyWebApp /grant "IIS AppPool\DefaultAppPool:(OI)(CI)RX"

Para más información, consulte el tema icacls.

Compatibilidad con HTTP/2

HTTP/2 es compatible con ASP.NET Core en los escenarios de implementación de IIS siguientes:

• En proceso
  • Windows Server 2016/Windows 10 o posterior; IIS 10 o posterior
  • Conexión con TLS 1.2 o una versión posterior
• Fuera de proceso
  • Windows Server 2016/Windows 10 o posterior; IIS 10 o posterior
  • Las conexiones de servidor perimetral de acceso público usan HTTP/2, pero la conexión de proxy inverso al servidor de Kestrel usa HTTP/1.1.
  • Conexión con TLS 1.2 o una versión posterior

Para una implementación dentro del proceso cuando se establece una conexión HTTP/2, HttpRequest.Protocol notifica HTTP/2. Para una implementación fuera del proceso cuando se establece una conexión HTTP/2, HttpRequest.Protocol notifica HTTP/1.1.

Para más información sobre los modelos de hospedaje en proceso y fuera de proceso, vea Módulo ASP.NET Core (ANCM) para IIS.

HTTP/2 está habilitado de forma predeterminada. Las conexiones vuelven a HTTP/1.1 si no se establece una conexión HTTP/2. Para más información sobre la configuración HTTP/2 con implementaciones de IIS, vea HTTP/2 en IIS.

Solicitudes CORS de preflight

Esta sección solo se aplica a las aplicaciones de ASP.NET Core que tienen como destino .NET Framework.

Para una aplicación de ASP.NET Core que tiene como destino .NET Framework, las solicitudes OPTIONS no se pasan a la aplicación de forma predeterminada en IIS. Para obtener información sobre cómo configurar los controladores de IIS de la aplicación en web.config para pasar las solicitudes OPTIONS, consulte Habilitar solicitudes entre orígenes en ASP.NET Web API 2: Cómo funciona la CORS.

Módulo de inicialización de aplicaciones y tiempo de espera de inactividad

Cuando se hospeda en IIS mediante la versión 2 del módulo de ASP.NET Core:

• Módulo de inicialización de aplicaciones: las aplicaciones hospedadas dentro de proceso o fuera de proceso se pueden configurar para iniciarse de forma automática en un reinicio de proceso de trabajo o un reinicio de servidor.
• Tiempo de espera de inactividad: Las aplicaciones hospedadas dentro de proceso se pueden configurar para que no tengan tiempo de espera durante períodos de inactividad.

Módulo de inicialización de aplicaciones

Se aplica a las aplicaciones hospedadas dentro de proceso y fuera de proceso.

Inicialización de aplicaciones de IIS es una característica de IIS que envía una solicitud HTTP a la aplicación al iniciarse o reciclarse el grupo de aplicaciones. La solicitud desencadena el inicio de la aplicación. De forma predeterminada, IIS emite una solicitud a la dirección URL raíz de la aplicación (/) para inicializar esta (consulte los recursos adicionales para más detalles sobre la configuración).

Confirme que la característica de rol Inicialización de aplicaciones de IIS está habilitada:

En Windows 7 o sistemas de escritorio posteriores cuando se usa IIS localmente:

1. Vaya a Panel de control>Programas>Programas y características>Activar o desactivar las características de Windows (lado izquierdo de la pantalla).
2. Abra Internet Information Services>Servicios World Wide Web>Características de desarrollo de aplicaciones.
3. Active la casilla de Inicialización de aplicaciones.

En Windows Server 2008 R2 o posterior:

1. Abra el Asistente para agregar roles y características.
2. En el panel Seleccionar servicios de rol, abra el nodo Desarrollo de aplicaciones.
3. Active la casilla de Inicialización de aplicaciones.

Use cualquiera de los enfoques siguientes para habilitar el módulo de inicialización de aplicaciones para el sitio:

• Mediante el Administrador de IIS:

  1. Seleccione Grupos de aplicaciones en el panel Conexiones.
  2. Haga clic con el botón derecho en el grupo de aplicaciones de la aplicación en la lista y seleccione Configuración avanzada.
  3. El valor predeterminado de Modo de inicio es OnDemand. Establezca el Modo de inicio en AlwaysRunning. Seleccione Aceptar.
  4. Abra el nodo Sitios en el panel Conexiones.
  5. Haga clic con el botón derecho en la aplicación y seleccione Administrar sitio web>Configuración avanzada.
  6. El valor predeterminado de Carga previa activada es False. Establezca Carga previa activada en True. Seleccione Aceptar.

• Mediante web.config, agregue el elemento <applicationInitialization> con doAppInitAfterRestart establecido en true a los elementos <system.webServer> del archivo web.config de la aplicación:

  <?xml version="1.0" encoding="utf-8"?>
  <configuration>
    <location path="." inheritInChildApplications="false">
      <system.webServer>
        <applicationInitialization doAppInitAfterRestart="true" />
      </system.webServer>
    </location>
  </configuration>
  

Tiempo de espera de inactividad

Solo se aplica a las aplicaciones hospedadas dentro de proceso.

Para evitar la inactividad en la aplicación, establezca el tiempo de espera de inactividad del grupo de aplicaciones mediante el Administrador de IIS:

1. Seleccione Grupos de aplicaciones en el panel Conexiones.
2. Haga clic con el botón derecho en el grupo de aplicaciones de la aplicación en la lista y seleccione Configuración avanzada.
3. El valor predeterminado de Tiempo de espera de inactividad (minutos) es 20 minutos. Establezca Tiempo de inactividad (minutos) en 0 (cero). Seleccione Aceptar.
4. Desactive y vuelva a activar el proceso de trabajo.

Para evitar que las aplicaciones hospedadas fuera de proceso agoten el tiempo de espera, use cualquiera de los enfoques siguientes:

• Haga ping a la aplicación desde un servicio externo con el fin de mantenerla funcionando.
• Si la aplicación solo hospeda servicios en segundo plano, evite el hospedaje de IIS y use un servicio de Windows para hospedar la aplicación de ASP.NET Core.

Recursos adicionales del módulo de inicialización de aplicaciones y del tiempo de espera de inactividad

• Inicialización de aplicaciones IIS 8.0
• Inicialización de aplicaciones <applicationInitialization>.
• Configuración del modelo de proceso para un grupo de aplicaciones <processModel>.

Ubicaciones del módulo, el esquema y el archivo de configuración

Module

IIS (x86/amd64) :

• %windir%\System32\inetsrv\aspnetcore.dll

• %windir%\SysWOW64\inetsrv\aspnetcore.dll

• %ProgramFiles%\IIS\Asp.Net Core Module\V2\aspnetcorev2.dll

• %ProgramFiles(x86)%\IIS\Asp.Net Core Module\V2\aspnetcorev2.dll

IIS Express (x86/amd64) :

• %ProgramFiles%\IIS Express\aspnetcore.dll

• %ProgramFiles(x86)%\IIS Express\aspnetcore.dll

• %ProgramFiles%\IIS Express\Asp.Net Core Module\V2\aspnetcorev2.dll

• %ProgramFiles(x86)%\IIS Express\Asp.Net Core Module\V2\aspnetcorev2.dll

Schema

IIS

• %windir%\System32\inetsrv\config\schema\aspnetcore_schema.xml

• %windir%\System32\inetsrv\config\schema\aspnetcore_schema_v2.xml

IIS Express

• %ProgramFiles%\IIS Express\config\schema\aspnetcore_schema.xml

• %ProgramFiles%\IIS Express\config\schema\aspnetcore_schema_v2.xml

Configuración

IIS

• %windir%\System32\inetsrv\config\applicationHost.config

IIS Express

• Visual Studio: {APPLICATION ROOT}\.vs\config\applicationHost.config

• CLI de iisexpress.exe: %USERPROFILE%\Documents\IISExpress\config\applicationhost.config

Los archivos se pueden encontrar mediante la búsqueda de aspnetcore en el archivo applicationHost.config.

Instalación de Web Deploy al publicar con Visual Studio

Al implementar aplicaciones en servidores con Web Deploy, instale la versión más reciente de Web Deploy en el servidor. Para instalar Web Deploy, obtenga un instalador del Centro de descarga de Microsoft.

Creación del sitio de IIS

1. En el sistema de hospedaje, cree una carpeta para que contenga los archivos y las carpetas publicados de la aplicación. En un paso posterior, la ruta de acceso de la carpeta se proporciona a IIS como la ruta de acceso física a la aplicación. Para más información sobre el diseño de carpetas y archivos de implementación de una aplicación, consulte Estructura de directorios de ASP.NET Core.

2. En Administrador de IIS, abra el nodo del servidor en el panel Conexiones. Haga clic con el botón derecho en la carpeta Sitios. Haga clic en Agregar sitio web en el menú contextual.

3. Proporcione el Nombre del sitio y establezca la Ruta de acceso física a la carpeta de implementación de la aplicación. Proporcione la configuración de Enlace y cree el sitio web seleccionando Aceptar:

   

   Advertencia

   Los enlaces de carácter comodín de nivel superior (http://*:80/ y http://+:80) no se deben usar. Los enlaces de carácter comodín de nivel superior pueden exponer su aplicación a vulnerabilidades de seguridad. Esto se aplica tanto a los caracteres comodín fuertes como a los débiles. Use nombres de host explícitos en lugar de caracteres comodín. Los enlaces de carácter comodín de subdominio (por ejemplo, *.mysub.com) no suponen este riesgo de seguridad si se controla todo el dominio primario (a diferencia de *.com, que sí es vulnerable). Consulte RFC 9110: Semántica HTTP (Sección 7.2: Host y :authority) para más información.

4. En el nodo del servidor, seleccione Grupos de aplicaciones.

5. Haga clic con el botón derecho en el grupo de aplicaciones del sitio y seleccione Configuración básica en el menú contextual.

6. En la ventana Modificar grupo de aplicaciones, establezca Versión de .NET CLR en Sin código administrado:

   

   ASP.NET Core se ejecuta en un proceso independiente y administra el runtime. ASP.NET Core no se basa en la carga de CLR de escritorio (.NET CLR). Core Common Language Runtime (CoreCLR) para .NET Core se arranca para hospedar la aplicación en el proceso de trabajo. El establecimiento de Versión de .NET CLR en Sin código administrado es opcional, pero no es lo recomendable.

   • En el caso de las implementaciones independientes de 32 bits (x86) publicadas con un SDK de 32 bits que use el modelo de hospedaje en proceso, habilite el grupo de aplicaciones para 32 bits. En el Administrador de IIS, vaya a Grupos de aplicaciones en la barra lateral Conexiones. Seleccione el grupo de aplicaciones de la aplicación. En la barra lateral Acciones, seleccione Configuración avanzada. Establezca Habilitar aplicaciones de 32 bits en True.

   • En el caso de las implementaciones independientes de 64 bits (x64) en las que se use un modelo de hospedaje en proceso, deshabilite el grupo de aplicaciones de los procesos de 32 bits (x86). En el Administrador de IIS, vaya a Grupos de aplicaciones en la barra lateral Conexiones. Seleccione el grupo de aplicaciones de la aplicación. En la barra lateral Acciones, seleccione Configuración avanzada. Establezca Habilitar aplicaciones de 32 bits en False.

7. Confirme que la identidad del modelo de proceso tiene los permisos adecuados.

   Si cambia la identidad predeterminada del grupo de aplicaciones (modelo de proceso>Identity) de ApplicationPoolIdentity a otra identidad, compruebe que la nueva identidad tenga los permisos necesarios para acceder a la carpeta de la aplicación, la base de datos y otros recursos necesarios. Por ejemplo, el grupo de aplicaciones requiere acceso de lectura y escritura a las carpetas donde la aplicación lee y escribe archivos.

Configuración de la autenticación de Windows (opcional)
Para más información, consulte Configurar la autenticación de Windows.

Instantánea

La creación de instantáneas de los ensamblados de la aplicación en el módulo de ASP.NET Core (ANCM) para IIS ofrece una mejor experiencia de usuario final que detener la aplicación mediante la implementación de un archivo sin conexión de la aplicación.

Cuando una aplicación de ASP.NET Core se ejecuta en Windows, los archivos binarios se bloquean para que no se puedan modificar ni reemplazar. La creación de instantáneas permite actualizar los ensamblados de la aplicación mientras esta se ejecuta mediante la realización de una copia de los ensamblados.

Una instantánea no está pensada para habilitar la implementación sin tiempo de inactividad, por lo que se espera que IIS siga reciclando la aplicación y algunas solicitudes pueden obtener una respuesta 503 Servicio no disponible. Se recomienda usar un patrón como el de las implementaciones azul-verde o las ranuras de implementación de Azure para implementaciones sin tiempo de inactividad. La instantánea ayuda a minimizar el tiempo de inactividad en las implementaciones, pero no puede eliminarlo por completo.

La creación de instantáneas se habilita mediante la personalización de la configuración del controlador ANCM en web.config:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.webServer>
    <handlers>
      <remove name="aspNetCore"/>
      <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified"/>
    </handlers>
    <aspNetCore processPath="%LAUNCHER_PATH%" arguments="%LAUNCHER_ARGS%" stdoutLogEnabled="false" stdoutLogFile=".logsstdout">
      <handlerSettings>
        <handlerSetting name="enableShadowCopy" value="true" />
        <!-- Ensure that the IIS ApplicationPool identity has permission to this directory -->
        <handlerSetting name="shadowCopyDirectory" value="../ShadowCopyDirectory/" />
      </handlerSettings>
    </aspNetCore>
  </system.webServer>
</configuration>