msdeploy (Web Deploy) fallando con 401 problemas de autenticación

Asumo que ha configurado su servidor correctamente para WebDeploy 2.0 según este artículo:

Configurar Web Deploy (IIS.NET)

Nota: MS ha lanzado una actualización de Web Deploy 2.0 y el enlace original ya no es válido. He actualizado esto, pero creo que será un objetivo en movimiento con el tiempo.

También necesita instalar Web Deploy 2.0 en su máquina de desarrollo/compilación/CI.

Si todavía estás usando 1.0 entonces recomiendo actualizar, hay algunas mejoras enormes en 2.0.

Usando la función de Publicación de Visual Studio 2010:

Visual Studio puede publicar un sitio haciendo clic derecho en el sitio y seleccionando "Publicar". Esto trae el siguiente diálogo:

Hay un par de gotcha con Visual Studio 2010 y WebDeploy 2.0. La primera es que VS2010 no es compatible con WebDeploy/MSDeploy 2.0. Así que si intenta publicar obtendrá un error como el siguiente:

Error 1 Tarea de implementación web fallar.((04/02/2011 12:30: 40) Un error ocurrió cuando la solicitud fue procesado en el equipo remoto.)

También verá el siguiente error en el Seguimiento de solicitudes fallidas para el servicio de administración web en el servidor en C:\inetpub\logs\wmsvc\TracingLogFiles\W3SVC1 asumiendo que tiene esto activado:

AspNetModuleDiagErrorEvent {[69]]} Uri / msdeploy.axd
eventData Seguimiento despliegue excepción de agente. ID de solicitud ''. Solicitar Marca de Tiempo: '02/04/2011
Sistema.UnauthorizedAccessException: Se deniega el acceso a la ruta 'D:\'.

La letra de la unidad variará según la unidad en la que se encuentre su sitio de IIS.

Fuera de la caja, el mecanismo de publicación in-GUI utiliza por defecto la versión incorrecta de MSDeploy (1.0). Queremos decirle a VS2010 que use MSDeploy 2.0. Puede hacer esto editando el archivo devenv.exe.config de Visual Studio 2010 que se encuentra en (suponiendo que hizo una instalación de unidad predeterminada c:\):

Para sistemas de 64 bits: c:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE Para sistemas de 32 bits: c:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE

Abre devenv.exe.config en tu editor XML favorito (acabo de usar Visual Studio 2010) y copia el siguiente xml:

<dependentAssembly>
  <assemblyIdentity 
    name="Microsoft.Web.Deployment" 
    publicKeyToken="31bf3856ad364e35" culture="neutral"/>
  <bindingRedirect oldVersion="7.1.0.0" newVersion="8.0.0.0"/>
</dependentAssembly>

Añadir esto a la /configuration/runtime/assemblyBinding sección:

Una vez hecho esto, cierre todas las instancias de Visual Studio 2010 para permitir que este cambio surta efecto. Reinicie VS2010, abra un proyecto web y luego intente publicar nuevo. Esta vez debería tener éxito.

Publicar usando un paquete de compilación:

Visual Studio puede producir un paquete de compilación que se puede ejecutar desde la línea de comandos. Esto se genera usando Project -> Build Deployment Package. Útil para la integración continua y similares (el paquete también se puede generar usando msbuild con el conmutador /t:Package).

La carpeta de salida del paquete suele ser obj\Package.

Desafortunadamente Visual Studio 2010 se equivoca un poco y genera un script por lotes de msdeploy wrapper targetting 1.0 y targetting deployment en el servidor en lugar de a nivel de sitio.

No hay una solución rápida para esto que no sea crear su propio msdeploy.línea de comandos exe. He dividido esto en varias líneas para hacer esto un poco más legible.:

"C:\Program Files\IIS\Microsoft Web Deploy v2\\msdeploy.exe"
  -source:archiveDir='d:\sites\DemoApp\obj\Package\Archive' 
  -dest:
       auto,
       computerName='https://yoursite.com:8172/msdeploy.axd?site=yoursitename',
       userName='demosite',
       password='somepassword',
       authtype='basic',
       includeAcls='False' 
  -verb:sync 
  -disableLink:AppPoolExtension 
  -disableLink:ContentExtension 
  -disableLink:CertificateExtension 
  -setParamFile:"d:\sites\DemoApp\obj\Package\Archive.SetParameters.xml"   
  -allowuntrusted

Lo primero a tener en cuenta es el camino a msdeploy.exe. Visual Studio genera una ruta a la versión 1.0. He cambiado esto para usar 2.0.

Notable parámetros:

-source:archiveDir= indica a msdeploy que estamos implementando un paquete y proporciona la ubicación local

computerName='https://yoursite.com:8172/msdeploy.axd?site=yoursitename' - esto le indica a MSDEPLOY que se implemente en un sitio específico en IIS7. yoursitename debe coincidir exactamente con el nombre del sitio en IIS.

userName y password are es el nombre del usuario administrador delegado para el sitio. Esto se configura mediante la función "Permisos del administrador de IIS" a nivel del sitio. La cuenta debe ser una cuenta de usuario local de Windows.

-authtype='basic' - esto fuerza la autenticación básica, de lo contrario se intenta la autenticación NTLM.

-allowuntrusted - esto ignora cualquier error de certificado SSL si utiliza el certificado SSL auto-firmado incorporado.

Si usa esa línea de comandos, debería poder implementarla en un servidor IIS7 remoto con éxito.

Publicar Contenido en bruto:

A veces queremos simplemente publicar algún contenido estático (o tal vez incluso un sitio clásico ASP o PHP) directamente desde una carpeta local. Podemos hacer esto usando la siguiente línea de comandos msdeploy.exe:

"C:\Program Files\IIS\Microsoft Web Deploy v2\\msdeploy.exe" 
  -source:contentPath='d:\websites\mysite' 
  -dest:
     contentPath='yoursitename',
     computerName='https://yoursite.com:8172/msdeploy.axd?site=yoursitename',
     userName='demosite',
     password='somepassword',
     authtype='basic',
     includeAcls='False' 
-verb:sync 
-allowuntrusted 

Nuevamente se aplican las mismas reglas que antes para -dest:contentPath y computerName.

Creo que los problemas de versión de MSDeploy se resolverán en SP1 (que aún no he tenido la oportunidad de ver).

Un final VS2010 Gotcha:

Al publicar con Visual Studio 2010, el paquete de compilación" Publicar " hace que las ACL de la cuenta anónima del sitio cambien a Solo Lectura para todos los archivos y carpetas con la excepción de la carpeta App_Data que se cambia a Lectura y Escritura.

Esto se puede solucionar agregando la siguiente configuración al archivo .csproj debajo de cada <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">:

<IncludeSetAclProviderOnDestination>False</IncludeSetAclProviderOnDestination>

O si estás usando msbuild:

msbuild.exe myproject.csproj /t:Package /p:IncludeSetAclProviderOnDestination=False

Encontré esa pepita útil de aquí: {[30]]}

Omitir la configuración de una ACL en un paquete de implementación de Visual Studio 2010 (enlace WayBackMachine porque el contenido original ya no está disponible)