visual tutorial temas studio para mejores las extensiones español ejecutar code autocompletar visual-studio-2010 msbuild tfs2010 msdeploy

visual studio 2010 - tutorial - ¿Cómo puedo hacer que TFS2010 ejecute MSDEPLOY a través de MSBUILD?



temas para visual studio code (8)

Hay una excelente charla de 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 él no entra en TFS).

Puede usar MSBUILD dentro de TFS2010 para llamar a MSDEPLOY y desplegar su paquete en IIS. Esto se hace por medio de 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?

He pasado todo el día tratando de hacer que esto funcione y no puedo hacerlo bien y sigo teniendo varios errores. Si ejecuto el archivo cmd del paquete, se despliega perfectamente. Si ejecuto WebDeploy a través de Visual Studio también funciona perfectamente.

Pero quiero que toda la implementación se ejecute a través de msbuild usando estos argumentos y no una llamada separada a msdeploy o ejecutando el paquete .cmd . ¿Cómo puedo hacer esto?

PD. Sí, tengo el Web Deployment Agent Service ejecución. También tengo el servicio de administración ejecutándose bajo IIS. He intentado usar ambos.

Args 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): Error de VsMsdeploy. (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 la computadora de destino.) Detalles del error: 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 la computadora 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 la publicación de en este hilo / pregunta.

Pero cuando se trata de la configuración de MSBuild ... la mayoría de la gente usa la siguiente configuración: /p:MSDeployPublishMethod=RemoteAgent que NO /p:MSDeployPublishMethod=RemoteAgent DERECHO 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 para autenticarse necesita ser un administrador. Que está fraqueado (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): la tarea de implementación web falló. (Agente remoto (URL http://your-web-server/MSDEPLOYAGENTSERVICE ) no se pudo contactar. Asegúrese de que el servicio del agente remoto esté instalado e iniciado en la computadora 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, póngase en contacto con su administrador local o del servidor. Detalles de error: no se pudo contactar con el agente remoto (URL http://your-web-server/MSDEPLOYAGENTSERVICE ). Asegúrese de que el servicio del agente remoto esté instalado e iniciado en la computadora 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 MSDeployPublishMethod a esto:

/p:MSDeployPublishMethod=WMSVC

WMSVC significa Windows Manager Service. Básicamente es un envoltorio más nuevo que el Remote Agent, pero ahora nos permite corregir el proporcionar un nombre de usuario y contraseña ... ¡donde el usuario NO tiene que ser un administrador! (¡alegría!) Así que ahora puedes corregir a qué usuarios quieres tener acceso ... por sitio web ...

Ahora también intenta https://your-web-server:8172/MsDeploy.axd la url: https://your-web-server:8172/MsDeploy.axd <- ¡lo cual es EXACTAMENTE lo que hace la ventana de Publish Visual Studio 2010! (OMG -> PENNY DROPS !! ¡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

Tenga en cuenta que el nombre de usuario tiene el nombre de dominio en él? Ya lo necesitas, allí. 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 para el grupo de Domain Users del Domain Users ... así es como funciona todo.

Ahora, si leíste todo esto, ten un lolcat (porque son SOOOOOOOO 2007) ...

Aquí están los pasos que finalmente funcionó para mí. Quería trabajar 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úrate de que el servicio se haya iniciado
  • Configure un usuario de IIS (haga clic en el MOST SERVERNAME SUPERIOR en IIS) y vaya a ''Usuarios de IIS Manager''. Sugiero que sea diferente a tu nombre de Windows.
  • Asegúrese de que la cuenta de usuario de WMSVC (SERVICIO LOCAL para mí) tenga permisos de escritura en el directorio de IIS que está utilizando
  • En mi caso, estoy usando un certificado SSL (aunque está golpeando localhost).

Recuerde que estos son todos los argumentos a 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 apuntando a 127.0.0.1. Localhost probablemente también trabaje aquí.

Artículos útiles:

Solución de problemas de MSDeploy

Más resolución de problemas

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 servidor web dev server windows server 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 ayuda.

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

  1. El elemento con el que luché al principio fueron las citas sobre "Sitio web predeterminado / Your ApplicationNameHere" que da el error parcial:

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

    Esto sucede cuando no hay citas en el Sitio web predeterminado / YourApplicationNameHere

  2. El siguiente error que recibí fue por el nombre de usuario y 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 despliegue web. (Agente remoto (URL https://devserver02:8172/msdeploy.axd?site=Default Sitio web https://devserver02:8172/msdeploy.axd?site=Default ) no se pudo contactar. Asegúrese de que el servicio del agente remoto esté instalado e iniciado en la computadora 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, póngase en contacto con su administrador local o del servidor. Detalles del error: no se pudo contactar con el agente remoto (URL https://devserver02:8172/msdeploy.axd?site=Default Sitio web https://devserver02:8172/msdeploy.axd?site=Default ). Asegúrese de que el servicio del agente remoto esté instalado e iniciado en la computadora 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 debía a que el nombre de usuario y la contraseña que tenía en / p: Nombre de usuario = / p: Contraseña = no incluían el dominio para el usuario. A pesar de que la construcción se estaba ejecutando bajo ese usuario, no se implementaría. Así que https://devserver02:8172/msdeploy.axd la URL directamente https://devserver02:8172/msdeploy.axd en un navegador para asegurarme de que funcionaba y me aseguré de que funcionaran el nombre de usuario y la contraseña. Aquí es donde noté que tenía que poner en el dominio / usuario para que funcione.

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

Lamentablemente, no hay mucha información sobre esto en este momento. Sin embargo, te daré algunos consejos al final de este mensaje.

Sobre su problema, he visto esto antes cuando intentaba implementar usando MSDeploy y la cuenta en la que estaba corriendo 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 en la que se ejecutan sus compilaciones y ver si esta cuenta tiene los derechos para implementar en la máquina de destino. Si no, entonces tienes algunas opciones; otorgarle los derechos al usuario de compilación o pasar el nombre de usuario / contraseña en.

Si desea pasar los valores, tendrá que definir un elemento llamado MsDeployDestinationProviderSetting y sus metadatos deberán contener los valores necesarios.

Entonces, en su archivo de proyecto (o a través de 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 mucho por hacer. Pero dado que todo el Pipeline 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, observará 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, debes inspeccionar esos archivos y aprender por ti mismo.

Voy a estar trabajando en algo que cubrirá estas tecnologías en detalle, pero no estará disponible por bastante tiempo, y todavía tengo mucho que descubrir acerca de esto.

¿Puedes probar el trato de nombre de usuario / contraseña y decirme si funcionó para ti?

Para mí, el problema fue que el Web Deployment Agent Service no se inició.

Un simple net start msdepsvc arregló. También podría establecer 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 este modo, utiliza las credenciales del agente de compilación TFS para la implementación). ver la respuesta aceptada aquí

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

He utilizado la actividad de 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 del flujo de trabajo de CopyDirectory, configurando el origen 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 construcción fue exitosa antes de invocar la actividad de CopyDirectory. Los artículos que mencioné muestran cómo hacerlo. También enseñan cómo invocar un script powershell en lugar de CopyDirectory.

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

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: // mi-nombre-servidor / p: username = minombredeusuario / p: contraseña = 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 al usar InProc (que puede ser el valor 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 correctamente. Noté que el archivo Package ya no está en la carpeta MyWebApplication_Package, pero eso no es un gran problema para mí.