¿Cómo puedo hacer que TFS2010 ejecute MSDEPLOY por mí a través de MSBUILD?

Hay una excelente charla sobre PDC disponible aquí de Vishal Joshi que describe las nuevas características de MSDEPLOY en Visual Studio 2010, así como también cómo implementar una aplicación dentro de TFS. (También hay una gran charla de Scott Hanselman, pero no entra en TFS).

Puede usar MSBUILD dentro de TFS2010 para llamar a MSDEPLOY para implementar su paquete en IIS. Esto se hace mediante parámetros a MSBUILD.

La charla explica algunos de los parámetros de la línea de comandos como:

/p:DeployOnBuild
/p:DeployTarget=MsDeployPublish
/p:CreatePackageOnPublish=True
/p:MSDeployPublishMethod=InProc
/p:MSDeployServiceURL=localhost
/p:DeployIISAppPath="Default Web Site"

Pero, ¿dónde está la documentación para esto? No puedo encontrar ninguna?

Me he pasado todo el día tratando de que esto funcione y no puedo hacerlo bien y sigo terminando con varios errores. Si ejecuto el cmdarchivo del paquete, se implementa perfectamente. Si ejecuto WebDeploy a través de Visual Studio, también funciona perfectamente.

Pero quiero que toda la implementación se ejecute msbuildutilizando estos argumentos y no una llamada separada msdeployo ejecutando el .cmdarchivo del paquete . ¿Cómo puedo hacer esto?

PD. Sí, tengo la Web Deployment Agent Servicecarrera. También tengo el servicio de administración que se ejecuta bajo IIS. Intenté usar ambos.

Args que estoy usando:

/p:DeployOnBuild=True 
/p:DeployTarget=MsDeployPublish 
/p:Configuration=Release 
/p:CreatePackageOnPublish=True  
/p:DeployIisAppPath=staging.example.com   
/p:MsDeployServiceUrl=https://staging.example.com:8172/msdeploy.axd 
/p:AllowUntrustedCertificate=True

dando me :

C: \ Archivos de programa (x86) \ MSBuild \ Microsoft \ VisualStudio \ v10.0 \ Web \ Microsoft.Web.Publishing.targets (2660): Falló la implementación de VsMs. (Agente remoto (URL https://staging.example.com: 8172 / msdeploy.axd? Site = staging.example.com ) no se pudo contactar. Asegúrese de que el servicio del agente remoto esté instalado e iniciado en el equipo de destino.) Detalle del error: Agente remoto (URL https: //staging.example. com: 8172 / msdeploy.axd? site = staging.example.com ) no pudo ser contactado. Asegúrese de que el servicio de agente remoto esté instalado e iniciado en el equipo de destino. Se recibió una respuesta no admitida. El encabezado de respuesta 'MSDeploy.Response' era '' pero se esperaba 'v1'. El servidor remoto devolvió un error: (401) No autorizado.

Respuesta relacionada con IIS7 + ....

Ok, esto es lo que terminé haciendo. Más o menos, siguiendo el post de Simon Weaver en este hilo / pregunta.

Pero cuando se trata de la configuración de MSBuild ... la mayoría de la gente aquí está usando la siguiente configuración: /p:MSDeployPublishMethod=RemoteAgentque NO es ADECUADA para IIS7. El uso de esta configuración significa que TFS intenta conectarse a la URL: https://your-server-name/MSDEPLOYAGENTSERVICE pero para acceder a esa URL, el usuario que debe autenticarse debe ser un administrador. Que está fraked. (Y debe tener marcada la regla de anulación de administrador). Esta URL es para IIS6, creo.

Aquí está el mensaje de error estándar cuando intenta conectarse usando RemoteAgent: -

Estándar 401 Frak Off u suck RemoteAgent, error

C: \ Archivos de programa (x86) \ MSBuild \ Microsoft \ VisualStudio \ v10.0 \ Web \ Microsoft.Web.Publishing.targets (3588): Error en la tarea de implementación web. (Agente remoto (URL http: // your-web- server / MSDEPLOYAGENTSERVICE ) no se pudo contactar. Asegúrese de que el servicio de agente remoto esté instalado e iniciado en el equipo de destino.) Asegúrese de que el nombre del sitio, el nombre de usuario y la contraseña sean correctos. Si el problema no se resuelve, comuníquese con su administrador local o del servidor. Detalles del error: agente remoto (URL http: // su-servidor-web / MSDEPLOYAGENTSERVICE) no se pudo contactar. Asegúrese de que el servicio de agente remoto esté instalado e iniciado en el equipo de destino. Se recibió una respuesta no admitida. El encabezado de respuesta 'MSDeploy.Response' era 'V1' pero se esperaba 'v1'. El servidor remoto devolvió un error: (401) No autorizado.

Entonces ... necesitas cambiar tu MSDeployPublishMethoda esto:

/p:MSDeployPublishMethod=WMSVC

Las WMSVCsiglas de Windows Manager Service. Es básicamente una envoltura más nueva sobre el Agente remoto, pero ahora nos permite proporcionar un nombre de usuario y una contraseña correctos ... ¡donde el usuario NO tiene que ser un administrador! (¡alegría!) Así que ahora puede corregir la configuración a qué usuarios desea tener acceso .. por sitio web ..

Ahora también intenta acceder a la URL: https://your-web-server:8172/MsDeploy.axd<- ¡que es EXACTAMENTE lo que hace la Publishventana de Visual Studio 2010 ! (¡¡Dios mío -> gotas de penny !! ¡BOOM!)

Y aquí está mi configuración final de MSBuild:

/p:DeployOnBuild=True
/p:DeployTarget=MSDeployPublish 
/p:MSDeployPublishMethod=WMSVC
/p:MsDeployServiceUrl=your-server-name
/p:DeployIISAppPath=name-of-the-website-in-iis7    
/p:username=AppianMedia\some-domain-user 
/p:password=JonSkeet<3<3<3
/p:AllowUntrustedCertificate=True

¿Se da cuenta de que el nombre de usuario tiene el nombre de dominio? Ya necesitas eso, ahí. Además, en mi imagen, he permitido que nuestros USUARIOS DE DOMINIO accedan al sitio web para su gestión. Como tal, mi nueva cuenta de usuario que agregué (TFSBuildService) tiene Membresía al Domain Usersgrupo ... así es como funciona todo.

Ahora, si ha leído todo esto, tenga un lolcat (porque son SOOOOOOOO 2007) ....

Estos son los pasos que finalmente me funcionaron. Quería que funcionara con RemoteAgent, pero no pude hacerlo funcionar sin importar lo que intenté.

No tienes que hacer exactamente esto, pero así es como lo hice funcionar.

• Configurar WMSVC
• Asegúrese de que el servicio esté iniciado
• Configure un usuario de IIS (haga clic en TOP MOST SERVERNAME en IIS) y vaya a 'Usuarios del Administrador de IIS'. Sugiero que sea diferente a su nombre de Windows.
• Asegúrese de que la cuenta de usuario de WMSVC (SERVICIO LOCAL para mí) tenga permisos de escritura en el directorio IIS que está utilizando
• En mi caso, estoy usando un certificado SSL (a pesar de que llega a localhost).

Recuerde que todos estos son argumentos para MSBUILD agregados dentro de la definición de compilación de TFS

/p:DeployOnBuild=True 
/p:DeployTarget=MSDeployPublish 
/p:MSDeployPublishMethod=WMSVC 
/p:MsDeployServiceUrl=https://staging.example.com:8172/msdeploy.axd 
/p:username=sweaveriis 
/p:password=abcd1234 
/p:DeployIisAppPath=staging.example.com/virtual_directory_name
/p:AllowUntrustedCertificate=True

Nota: staging.example.com es en realidad el cuadro local con una entrada de archivo de hosts que apunta a 127.0.0.1. Localhost probablemente también funcionaría aquí.

Artículos útiles:

Solución de problemas de MSDeploy

Más solución de problemas

Desafortunadamente, no hay mucha información sobre esto en este momento. Sin embargo, te daré algunas pistas al final de este mensaje.

Sobre su problema, he visto esto antes cuando intentaba implementar con MSDeploy y la cuenta en la que estaba ejecutando no tenía los permisos para ejecutar la implementación en la máquina de destino. Por lo tanto, debe echar un vistazo a la cuenta bajo la que se ejecutan sus compilaciones y ver si esta cuenta tiene los derechos para implementar en la máquina de destino. Si no es así, tiene algunas opciones; conceda los derechos al usuario de la compilación, o pase el nombre de usuario / contraseña.

Si desea pasar los valores, deberá definir un elemento con nombre MsDeployDestinationProviderSettingy sus metadatos deberán contener los valores necesarios.

Entonces, en su archivo de proyecto (o mediante las propiedades pasadas) defina algo como lo siguiente.

<PropertyGroup>
    <UserName>USERNAME-HERE</UserName>
    <Password>PASSWORD-HERE
</PropertyGroup>

Acerca de dónde puede encontrar documentación, como dije antes, todavía no hay mucha información disponible. Pero dado que todo el canal de publicación web se captura en objetivos y tareas de MSBuild, puede aprender mucho por su cuenta si está familiarizado con MSBuild. Si echa un vistazo a los archivos .csproj (o .vbproj) para proyectos web creados con Visual Studio 2010, notará una declaración como la siguiente:

<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" />

Esto importa el archivo ubicado en %ProgramFiles(x86)%\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets, y este archivo a su vez importa %ProgramFiles(x86)%\MSBuild\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets

Entonces, para aprender este tema en detalle en este momento, debe inspeccionar esos archivos y aprender por sí mismo.

Voy a estar trabajando en algo que cubrirá estas tecnologías en detalle, pero no saldrá por un tiempo, y todavía tengo mucho que resolver sobre estas cosas.

¿Puedes probar la oferta de nombre de usuario / contraseña y hacerme saber si funcionó para ti?

Tuve un problema similar y la solución fue tener el siguiente parámetro:

/ p: MSDeployPublishMethod = RemoteAgent

Aquí están todos los parámetros que utilicé.

/ p: DeployOnBuild = True / p: DeployTarget = MSDeployPublish / p: MSDeployPublishMethod = RemoteAgent / p: MsDeployServiceUrl = http: // my-server-name / p: username = myusername / p: password = mypassword

NOTA: No estoy usando DeployIisAppPath porque estoy creando una solución e intentando crear tres aplicaciones web a la vez. También creo que su MsDeployServiceUrl debería ser solo http://staging.example.com

Parece que cuando se usa InProc (que puede ser el predeterminado) para MSDeployPublishMethod, MSBuild ignora MsDeployServiceUrl y siempre intenta implementarlo en el servidor local. Lo cambié a RemoteAgent y las tres aplicaciones web se implementaron con éxito. Me di cuenta de que el archivo del paquete ya no está contenido en la carpeta MyWebApplication_Package, pero eso no es un gran problema para mí.

Tenga en cuenta que también puede configurar DeployTarget = Package; esto preparará el paquete pero no lo implementará de inmediato. Para obtener más información, consulte esta publicación de blog .

Para mí el problema fue que Web Deployment Agent Serviceno se inició.

Un simple lo net start msdepsvcarregló. También puede configurar el modo de inicio en Automático en este servicio.

Los argumentos que estoy usando son:

/p:DeployOnBuild=True 
/p:DeployTarget=MsDeployPublish 
/p:MSDeployPublishMethod=RemoteAgent 
/p:MSDeployServiceUrl=stagingserver 
/p:DeployIisAppPath=test.local 
/p:UserName=

Solo necesita especificar el nombre del servidor y no la ruta completa (no se necesita http).

Tenga en cuenta que UserName se deja vacío para solucionar un error con la autenticación NTLM (de esta manera, utiliza las credenciales del agente de compilación TFS para la implementación). ver la respuesta aceptada aquí

Así es como lo hice funcionar. Esto fue con Webdeploy 2.0. Estoy implementando en el mismo dominio desde nuestra máquina de compilación a una máquina dev webserver windows server 2008 r2. La cuenta que estoy usando para implementar es una cuenta de servicio en el dominio que tiene permisos de administrador en ambas máquinas. Mi solución incluye un par de proyectos de prueba unitaria, un proyecto mvc3 y un par de bibliotecas bajo la solución. Si no instala MVC3 en el servidor que está implementando, consulte http://www.iwantmymvc.com/2011-03-23-bin-deploy-aspnet-mvc-3-visual-studio para obtener orientación.

/ p: DeployOnBuild = True / p: DeployTarget = MSDeployPublish / p: DeployIisAppPath = "Sitio web predeterminado / YourpplicationNameHere" /p:MsDeployServiceUrl=https://devserver02:8172/msdeploy.axd / p: AllowUntrustedCertificate.axd / p: AllowUntrustedCertificate = yourDomain \buildaccount / p: Password = contraseña

1. El elemento con el que luché al principio fueron las citas en torno a "Sitio web predeterminado / Nombre de su aplicación aquí" Eso da el error parcial:

   MSBUILD: error MSB1008: solo se puede especificar un proyecto.

   Esto sucede cuando no hay comillas en el sitio web predeterminado / YourApplicationNameHere

2. El siguiente error que recibí fue debido al nombre de usuario y la contraseña incorrectos en mis credenciales para la implementación. Dio este error:

   C: \ Archivos de programa (x86) \ MSBuild \ Microsoft \ VisualStudio \ v10.0 \ Web \ Microsoft.Web.Publishing.targets (3588): Error en la tarea de implementación web. (Agente remoto (URL https: // devserver02: 8172 / msdeploy.axd? site = Sitio web predeterminado ) no se pudo contactar. Asegúrese de que el servicio de agente remoto esté instalado e iniciado en el equipo de destino.) Asegúrese de que el nombre del sitio, el nombre de usuario y la contraseña sean correctos. Si el problema no se resuelve, comuníquese con su administrador local o del servidor. Detalles del error: agente remoto (URL https: // devserver02: 8172 / msdeploy.axd? Site = DefaultSitio web) no se pudo contactar. Asegúrese de que el servicio de agente remoto esté instalado e iniciado en el equipo de destino. Se recibió una respuesta no admitida. El encabezado de respuesta 'MSDeploy.Response' era '' pero se esperaba 'v1'. El servidor remoto devolvió un error: (401) No autorizado.

   Esto se debió a que el nombre de usuario y la contraseña que tenía en / p: UserName = / p: Password = no incluían el dominio del usuario. Aunque la compilación se ejecutaba con ese usuario, no se implementaría. Entonces presioné la URL directamente https: // devserver02: 8172 / msdeploy.axd en un navegador para asegurarme de que estaba funcionando y asegurarme de que el nombre de usuario y la contraseña funcionaran. Aquí es donde noté que tenía que ingresar el dominio / usuario para que funcionara.

Espero que esté bien para responder, pensé que algún otro pobrecillo podría encontrar estos errores y esto podría ayudar ...

Si puede implementar sus aplicaciones con fileCopy, es fácil personalizar el flujo de trabajo de TFS para hacerlo.

He utilizado la actividad CopyDirectory, con la ayuda de estos artículos:

http://www.ewaldhofman.nl/post/2010/11/09/Part-14-Execute-a-PowerShell-script.aspx

y

http://geekswithblogs.net/jakob/archive/2010/09/01/tfs-team-build-2010-how-to-place-the-build-output.aspx

Muy simple y directo.

• Configuré el servicio de compilación con una cuenta de usuario que tiene privilegios de escritura en el recurso compartido deseado.

• A continuación, creé el paso de flujo de trabajo de CopyDirectory, configurando la fuente como BuildDetail.DropLocation + "_PublishedWebsites" y para el destino creé un argumento, que llamé "DeployPath", que se puede completar en la configuración de compilación.

• Ahora todavía tengo que implementar una prueba para verificar si la compilación fue exitosa antes de invocar la actividad CopyDirectory. Los artículos que mencioné muestran cómo hacer eso. También enseñan cómo invocar un script de PowerShell en lugar de CopyDirectory.