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

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

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 la que reside el dominio de la aplicación.

Derribando y recreando el dominio de la aplicación no afectará a las DLL espaciales de Sql Server en cuestión. Esas DLL son código no administrado que se cargan manualmente a través de llamadas interop LoadLibray. Por lo tanto, las DLL viven fuera del ámbito del dominio de la aplicación.

Para liberar los bloqueos de archivos, que el proceso de grupo de aplicaciones pone en ellos, debe reciclar el grupo de aplicaciones o descargar las DLL de la memoria manualmente.

El Microsoft.SQLServer.Tipos nuget package envía una clase que se utiliza para cargar el espacio dll llamados SqlServerTypes.Utilidad. Puede modificar el método LoadNativeAssemblies para descargar las DLL no administradas cuando se descarga el dominio de la aplicación. Con esta modificación cuando msdeploy copys la app_offline.htm el dominio de la aplicación descargará y luego descargará también las DLL administradas.

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. Asume que su aplicación es la única que se ejecuta en el proceso de trabajo que utiliza las DLL espaciales. Dado que 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.

Hay problemas conocidos con IIS y bloqueos de archivos (por qué aún no se resuelven).

La pregunta que quiero hacer es, sin embargo, si es necesario volver a desplegar estos archivos?

Reconozco los nombres de archivo y los recuerdo como archivos del sistema que ya deberían estar presentes en el servidor o simplemente no necesitan ser re-desplegados.

No tengo mucha experiencia cuando se trata de IIS, pero me he encontrado con este problema antes 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. Restablecer sitio web
4. inténtalo de nuevo
5. iisreset

Creo que lo que sería más fácil de hacer es hacer que estas DLL sean tan copilocales como verdaderas. Estoy asumiendo que estas DLL se extraen de la carpeta de archivos de programa. Intente marcarlos como copylocal true y haga una implementación.Intente detener cualquier proceso local de IIS que se ejecute en su máquina local.

Tenga cuidado de que no tiene uno de esos nuevos servicios de copia de seguridad en la nube en ejecución que está tomando bloqueos de archivos, y tampoco tiene cosas abiertas en el explorador o una herramienta de inspección DLL.

Creo que es un poco ridículo que la EM 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 convertirse en 1 de cada 10 veces.

Voy a resolver el problema con:

• dos aplicaciones MySite.A y MySite.B, donde solo se ejecuta uno a la vez.
• Siempre me desplazo al sitio inactivo.
• Si hay un problema durante la implementación, nunca causará que todo el sitio se caiga.
• Si hay un problema importante después de la implementación, puede revertir muy fácilmente.

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