c# - una - subir aplicacion web iis

Publicación de VS2013 Error en la tarea de implementación web El archivo está en uso

Question

Estoy usando VS2013 Premium para publicar un sitio en Windows Server 2012. Todos los archivos se publican bien, excepto estos: SqlServerTypes / x64 / msvcr100.dll

SqlServerTypes / x64 / SqlServerSpatial110.dll

SqlServerTypes / x86 / msvcr100.dll

SqlServerTypes / x86 / SqlServerSpatial110.dll

Recibo este tipo de errores para cada uno de los archivos anteriores que traté de publicar: la tarea de implementación web falló. (El archivo ''msvcr100.dll'' está en uso. Obtenga más información en: http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_FILE_IN_USE .)

Curiosamente, estos archivos se publicaron la primera vez (cuando no estaban en el servidor) y luego ya no se sobrescriben. Probé con 2 servidores web diferentes. He seguido la guía aquí: http://blogs.msdn.com/b/webdev/archive/2013/10/30/web-publishing-updates-for-app-offline-and-usechecksum.aspx

... Pero solo logró desconectar el sitio (VS está colocando el app_offline.htm) pero la publicación aún falla con el mismo error. Todos los otros archivos se publican perfectamente.

¿Algunas ideas?

Answer 1

Creo que lo más fácil sería hacer que estos dll''s como CopyLocal sean verdaderos. Estoy asumiendo que estos archivos DLL se extrajeron de la carpeta de archivos de programa. Intente marcarlos como verdaderos copylocal y realice una implementación. Intente detener cualquier proceso local de IIS que se ejecute en su máquina local.

Answer 2

Hay problemas conocidos con IIS y bloqueos de archivos (por qué aún no están resueltos, no lo sé).

Sin embargo, la pregunta que quiero hacer es si incluso necesita volver a implementar estos archivos.

Reconozco los nombres de archivo y los recuerdo como archivos de sistema que ya deberían estar presentes en el servidor o simplemente no necesitan volver a implementarse.

No tengo mucha experiencia en lo que respecta a IIS, pero me he encontrado con este problema anteriormente y varios de mis compañeros de trabajo más experimentados me han dicho que esto es como dije un problema conocido de IIS y creo que la respuesta a su pregunta es :

1. Evite desplegar archivos innecesarios.
2. Inténtalo de nuevo
3. Resetear sitio web
4. Inténtalo de nuevo
5. iisreset

Answer 3

He encontrado la razón por la cual la solución en http://blogs.msdn.com/b/webdev/archive/2013/10/30/web-publishing-updates-for-app-offline-and-usechecksum.aspx no trabajo para el póster original, y tengo una solución alternativa.

El problema con el enfoque EnableMSDeployAppOffline es que solo recicla el dominio de la aplicación que aloja la aplicación. No recicla el proceso de trabajo del grupo de aplicaciones (w3wp.exe) en el que vive el dominio de la aplicación.

Destruir y volver a crear el dominio de la aplicación no afectará a los dlls espaciales de SQL Server en cuestión. Esos dlls son códigos no administrados que se cargan manualmente a través de llamadas de LoadLibray de interoperabilidad. Por lo tanto, los dlls viven fuera del ámbito del dominio de la aplicación.

Para liberar los bloqueos de archivos, que el proceso del grupo de aplicaciones les impone, debe reciclar el grupo de aplicaciones o descargar los dlls de la memoria manualmente.

El paquete nuget Microsoft.SqlServer.Types envía una clase que se usa para cargar los dlls espaciales denominados SqlServerTypes.Utilities. Puede modificar el método LoadNativeAssemblies para descargar los dlls no administrados cuando se descarga el dominio de la aplicación. Con esta modificación cuando msdeploy copie el app_offline.htm, el dominio de la aplicación se descargará y luego descargará los dlls administrados también.

private static IntPtr _msvcrPtr = IntPtr.Zero;
private static IntPtr _spatialPtr = IntPtr.Zero;

public static void LoadNativeAssemblies(string rootApplicationPath)
{
    if (_msvcrPtr != IntPtr.Zero || _spatialPtr != IntPtr.Zero)
        throw new Exception("LoadNativeAssemblies already called.");

    var nativeBinaryPath = IntPtr.Size > 4
        ? Path.Combine(rootApplicationPath, @"SqlServerTypes/x64/")
        : Path.Combine(rootApplicationPath, @"SqlServerTypes/x86/");

    _msvcrPtr = LoadNativeAssembly(nativeBinaryPath, "msvcr100.dll");
    _spatialPtr = LoadNativeAssembly(nativeBinaryPath, "SqlServerSpatial110.dll");

    AppDomain.CurrentDomain.DomainUnload += (sender, e) =>
    {
        if (_msvcrPtr != IntPtr.Zero)
        {
            FreeLibrary(_msvcrPtr);
            _msvcrPtr = IntPtr.Zero;
        }

        if (_spatialPtr != IntPtr.Zero)
        {
            FreeLibrary(_spatialPtr);
            _spatialPtr = IntPtr.Zero;
         }
    };
}

Hay una advertencia con este enfoque. Supone que su aplicación es la única que se ejecuta en el proceso de trabajo que está utilizando los dlls espaciales. Como los grupos de aplicaciones pueden alojar múltiples aplicaciones, los bloqueos de archivos no se liberarán si otra aplicación también los ha cargado. Esto evitará que su implementación funcione con el mismo error de bloqueo de archivo.

Answer 4

Puede sacar su aplicación fuera de línea durante la publicación, lo que, afortunadamente, debería liberar el bloqueo del archivo y permitirle actualizarlo.

http://blogs.msdn.com/b/webdev/archive/2013/10/30/web-publishing-updates-for-app-offline-and-usechecksum.aspx un tiempo. El soporte descrito se envió dentro de Azure SDK y Visual Studio Update. No recuerdo los lanzamientos exactos, pero puedo averiguar si es necesario. Cualquier actualización que data alrededor / después de esa publicación de blog debería estar bien.

Prerrequisitos:

• VS 2012 + VS update / VS 2013 + VS Update / VS2015
• MSDeploy v3

Nota: si está publicando desde un servidor de CI, el servidor de CI necesitará las actualizaciones anteriores también

Edite el perfil de publicación

En VS cuando se crea un perfil de publicación web, las configuraciones del cuadro de diálogo se almacenan en Properties/PublishProfiles/ Perfiles de publicación Properties/PublishProfiles/ como archivos que finalizan con .pubxml. Nota: también hay un archivo .pubxml.user , ese archivo no debe ser modificado

Para desconectar su aplicación en el archivo .pubxml , agregue la siguiente propiedad.

<EnableMSDeployAppOffline>true</EnableMSDeployAppOffline>

Notas

ASP.NET Requerido

La forma en que esto se ha implementado en el lado de MSDeploy es que un archivo app_offline.htm se descarta en la raíz del sitio web / aplicación. A partir de allí, el tiempo de ejecución de asp.net detectará eso y desconectará tu aplicación. Debido a esto, si su sitio web / aplicación no tiene asp.net habilitado, esta función no funcionará.

Casos en los que puede no funcionar

La implementación de esto hace que la aplicación no esté estrictamente desconectada antes de que se inicie la publicación. Primero, el archivo app_offline.htm se descarta, luego MSDeploy comenzará a publicar los archivos. No espera a que ASP.NET detecte el archivo y lo desconecte. Debido a esto, puede encontrarse con casos en los que aún se encuentre con el bloqueo de archivos. Por defecto, VS habilita las repeticiones, por lo que la aplicación se desconectará durante una de las pruebas y todo estará bien. En algunos casos puede tomar más tiempo para que ASP.NET responda. Eso es un poco más complicado.

En el caso de que agregue <EnableMSDeployAppOffline>true</EnableMSDeployAppOffline> y su aplicación no se desconecte lo suficientemente pronto, le sugiero que desconecte la aplicación antes de que comience la publicación. Hay varias formas de hacerlo de forma remota, pero eso depende de su configuración. Si solo tiene acceso a MSDeploy, puede probar la siguiente secuencia:

1. Use msdeploy.exe para desconectar su sitio al eliminar app_offline.htm
2. Use msdeploy.exe para publicar su aplicación (_segúrese de que la sincronización no elimine el archivo app_offline.htm_)
3. Espere una cierta cantidad de tiempo
4. Publica el sitio
5. Use msdeploy.exe para poner en línea la aplicación eliminando app_offline.htm

He escrito un blog sobre cómo puedes hacer esto en http://sedodream.com/2012/01/08/howtotakeyourwebappofflineduringpublishing.aspx . Lo único que falta en esa publicación de blog es la demora para esperar a que el sitio se desconecte. También puede crear un script que simplemente llame a msdeploy.exe directamente en lugar de integrarlo en el proceso de creación / publicación del proyecto.

Answer 5

Tenga en cuenta que no tiene uno de esos servicios de copia de seguridad en la nube que ejecutan bloqueos de archivos, y tampoco tiene cosas abiertas en el explorador ni en una herramienta de inspección de DLL.

Creo que es un poco ridículo que MS no haga mejores provisiones para este problema. Encuentro que 9 de cada 10 veces mi implementación funciona bien, pero luego, a medida que aumenta nuestro tráfico, puede volverse 1 de cada 10 veces.

Voy a resolver el problema con:

• dos aplicaciones MySite.A y MySite.B , donde solo una se ejecuta a la vez.
• Siempre me despliegue en el sitio inactivo.
• Si hay un problema durante la implementación, nunca hará que todo el sitio descienda.
• Si hay un problema importante después de la implementación, puede volver fácilmente.

No estoy seguro de cómo lo estoy implementando, pero creo que esto es lo que tengo que hacer.