.net - TFS 2010 Custom Build Activity TF215097 error

build-automation tfs2010 (14)

Para el proceso de compilación en TFS 2010, he creado una biblioteca que contiene algunas actividades de código personalizado. En el pasado, todo funcionaba bien agregando la biblioteca (* .dll) a Source Control y configurando la opción ''Build Controller - Version Control Path to Custom Assemblies'' en la ruta donde la biblioteca podría encontrarse en Source Control.

Pero desde hace unos días (y he estado actualizando la biblioteca a menudo) la construcción ya no tiene éxito. El error reportado es:

TF215097: Se produjo un error al inicializar una compilación para la definición de compilación "No se puede crear el tipo desconocido ''{clr-namespace: BuildTasks; assembly = BuildTasks}''"

Después de searching no pude encontrar otra solución que instalar la biblioteca en el GAC. Eso funciona, pero me pregunto por qué es imposible que funcione sin tener que instalarlo en el GAC.

Así que, aunque ahora vuelva a funcionar, me gustaría que vuelva a funcionar como antes, sin GAC. Esperemos que algunos de ustedes me puedan ayudar. Gracias por adelantado.

Como lo mencionó Rhapsody el 2 de junio de 2010, se puede utilizar el GAC. Sin embargo, debe tenerse en cuenta que si utiliza el GAC, debe detener y reiniciar el servicio de compilación, para que vuelva a escanear el GAC y, por lo tanto, seleccione su DLL.

Inicialmente había registrado mi DLL en el GAC, y cuando inicié una compilación que apuntaba a un flujo de trabajo que consistía en mi ensamblaje de actividad de código personalizado, la compilación falló. Pero después de detener y reiniciar el servicio de compilación, la compilación no falla de inmediato con el temido "Se produjo un error al inicializar una compilación para la definición de compilación [BuildDefinitionName]: no se puede crear un tipo desconocido ...".

Dado que no se da ninguna respuesta y no he encontrado ninguna solución, decidí ingresar al GAC ahora. Eso también funciona. :)

El atributo mencionado anteriormente es:

Microsoft.TeamFoundation.Build.Client.BuildActivity( Microsoft.TeamFoundation.Build.Client.HostEnvironmentOption.Agent )

En general, parece que TF215097 puede significar que "tus cosas están dañadas", no solo "no pude encontrarlo".

Encontré el mismo problema después de reiniciar nuestro servidor de compilación TFS 2012. Un trabajo de CI que se estaba ejecutando perfectamente bien dejó de funcionar con el error TF215097 mencionado, no pudo encontrar una actividad personalizada.

Un comentario en esta página ( https://social.msdn.microsoft.com/Forums/vstudio/en-US/479449e1-5c02-4744-b620-3bba64038cef/custom-build-activity-tf215097-cannot-create-unknown-type?forum=tfsbuild ) sugirió eliminar la ruta de origen del conjunto a las DLL de actividad personalizadas en la configuración del controlador de compilación, guardar la configuración actualizada, volver a agregar la misma ruta y volver a guardar.

Esto solucionó el problema para mí.

Es posible que esta solución no se aplique a todos los casos, ya que las respuestas proporcionadas en publicaciones anteriores son correctas, pero no fueron la solución a mi problema. Esta respuesta asume lo siguiente:

Los ensamblajes de soluciones personalizadas se modifican y se etiquetan y se crean correctamente.
El controlador de compilación ha apuntado a la ubicación de control de origen correcta para los ensamblajes personalizados.

Lo que yo y (sospecho que muchos otros) están haciendo es copiar o vincular sus documentos de flujo de trabajo xaml a la solución para que pueda usar el diseñador de flujo de trabajo y los nuevos ensamblados personalizados. Bueno, esto funciona muy bien en el diseñador de VS, pero VS modificará sus referencias de ensamblaje con las suyas propias. Por ejemplo, tengo una referencia que se parece a la siguiente:

xmlns:ca="clr-namespace:Custom.TFS.Activities;assembly=Custom.TFS.Activities"

Después de editar el flujo de trabajo con mi solución de proyecto, Visual Studio cambió eso a:

xmlns:local="clr-namespace:Custom.TFS.Activities"

Cuando marque este archivo para probar o usar, ahora verá el error TF215097.

La adición del ;assembly=your.assembly debe solucionar el problema y eliminar la necesidad de incluir todo en el GAC. Es posible que también deba corregir las referencias al espacio de nombres utilizando el resto del archivo xaml.

MUCHAS GRACIAS A: http://msmvps.com/blogs/rfennell/archive/2010/03/08/lessons-learnt-building-a-custom-activity-to-run-typemock-isolator-in-vs2010-team-build.aspx

Esto me funcionó: el nombre del ensamblaje debe incluirse en la declaración de espacio de nombres para el control personalizado:

http://blogs.microsoft.co.il/blogs/royrose/archive/2010/06/09/custom-build-activities-and-tf215097-error.aspx

Hoy no encontré una respuesta a este problema, así que probablemente esta respuesta llegue demasiado tarde para algunos de ustedes.

Estaba realmente atascado tratando de hacer lo mismo desde GAC, modificando la declaración del espacio de nombres y siempre encontraba el famoso "No se puede crear el tipo desconocido ''{clr-namespace: bla, bla, bla". Modificar todas las plantillas de compilación cada vez que puede agregar un nuevo ensamblaje es una experiencia dolorosa y molesta. Experimenté algunos problemas al configurar el ensamblaje en GAC, parece que hay algún tipo de caché porque las actividades personalizadas no se actualizaron incluso si desinstalé y reinstalé el ensamblado de GAC,

Finalmente, encontré en http://msdn.microsoft.com/en-us/library/ee330987.aspx que puede agregar ensamblajes personalizados con actividades personalizadas agregándolos a Source Control y configurando la ruta de control para ensamblados personalizados en Build Controller Properties (Puede acceder desde la Consola de administración de Team Foundation -> Crear configuración -> Propiedades del controlador)

Solo necesita agregar sus ensamblajes al control de código fuente y TFS se encargará de todo.

La solución que necesitaba era crear una definición de clase parcial de mi clase y aplicarle el atributo BuildActivity. Mi problema era que me faltaba el atributo BuildActivity en mi clase de actividad, ya que lo había implementado en Xaml suelto y no como actividad de código, por lo que esto lo solucionó.

Supuestamente, Team Build carga cualquier ensamblaje que contenga una clase con BuildActivity o BuildExtension, y en teoría esto debería dar como resultado que cualquier clase en dicho ensamblaje esté disponible para la compilación. Esto habría habilitado un tipo de clase de cargador ficticio que permitiría cargar las actividades de Xaml sin necesidad de estas definiciones parciales de clase, pero en la práctica eso no funcionó para mí.

Necesitas este atributo en tu clase codeActivity:

<BuildActivity (HostEnvironmentOption.All)> _

Por otra parte, el montaje no está cargado.

No tuve ningún éxito con las otras respuestas en este hilo, sin embargo, pensé que iba a compartir lo que hice. Mi ensamblaje personalizado se cargó en mi máquina de compilación a través de GAC. Tuve que abrir manualmente el archivo XAML de la plantilla de compilación y agregar mi ensamblaje a la referencia del espacio de nombres. Por alguna razón, Visual Studio no hacía referencia a esto correctamente para mí.

Antes de:

xmlns:ba1="clr-namespace:BuildTasks.Activities"

Después

xmlns:ba1="clr-namespace:BuildTasks.Activities;assembly=ModifyTasks"

Mi ensamblaje de tareas de compilación personalizado se llama ModifyTasks.dll. Reemplácelo con su propio nombre de archivo ...

Otra fuente de este error si, por error, mezcla extensiones de compilación para diferentes versiones de TFS. Por ejemplo, si está utilizando TFS 2012, pero intente usar las extensiones de compilación de TFS 2013 obtendrá este error.

Revise sus notificaciones de eventos de Windows. Es posible que su DLL de actividad personalizada NO se haya cargado correctamente.

Si no fue así, es posible que deba cambiar el destino de la plataforma de su proyecto de actividad personalizada ... ya sea a 32 bits o 64 bits.

Si desea especificar ensamblajes que contienen actividades de código personalizado que ha escrito, debe hacer lo siguiente:

Incorpore sus actividades personalizadas en su flujo de trabajo.
Asegúrese de que su xmlns en la parte superior esté definido correctamente: xmlns: local = "clr-namespace: BuildTasks; assembly = BuildTasks"
Asegúrese de que las etiquetas en el XAML para el proceso de construcción tengan el local (o cualquier prefijo que haya usado) correctamente.
Incorpore su XAML de flujo de trabajo actualizado en el proyecto de su equipo y actualice las definiciones de compilación.
Cree un nuevo directorio en el proyecto de su equipo llamado "CustomBuildAssemblies"
Vaya a la carpeta bin / Debug (o release) del proyecto que utilizó para crear las tareas de compilación personalizadas (básicamente obtenga la dll que está colocando en el GAC) y colóquela en el directorio creado en el paso 5.
Indique al controlador de compilación dónde buscar los ensamblados personalizados yendo a Team Exporer, seleccionando el proyecto para el que está haciendo esto, expanda la lista de proyectos y haga clic derecho en "Compilaciones", y seleccione "Administrar controladores de compilación". Venda el controlador (debe ser lo primero en la lista) y haga clic en Propiedades. Establezca la ruta de control de versión al directorio que se creó en el paso 5 (ubicado en el centro de la ventana emergente).

En este punto, tiene un flujo de trabajo XAML personalizado que hace referencia (importa) un ensamblado personalizado (o varios) que se han incluido en el control de origen. El controlador de compilación ahora sabe dónde se encuentran estos ensamblados personalizados. Esto le permite "registrar" nuevas versiones de esos ensamblajes personalizados si alguna vez necesita agregar / actualizar sus tareas de compilación personalizadas.

Esperemos que esto te ayude. Me tomó algo de tiempo para resolver esto también. Déjame saber si necesito hacer esto más detallado. Me gustaría poder publicar algunas capturas de pantalla de los diálogos.

ACTUALIZACIÓN: Me olvidé completamente de este hilo hasta que vi que fue revivido. También puedo actualizar esta respuesta ya que he encontrado una muy buena manera de hacer que TFS obtenga la última versión de su conjunto de tareas de compilación personalizada: hacer un número de versión único para el conjunto.

Utilizo una plantilla T4 y la ejecuto antes de construir el ensamblaje. Actualiza AssemblyInfo.cs después de leer el archivo DLL de actividad personalizado registrado.

<#@ template debug="false" hostspecific="true" language="C#" #> <#@ assembly name="System.Core" #> <#@ assembly name="System.Xml.dll" #> <#@ import namespace="System.Xml" #> <#@ import namespace="System.Linq" #> <#@ import namespace="System.Text" #> <#@ import namespace="System.Collections.Generic" #> <#@ import namespace="System.IO" #> <#@ import namespace="System.Reflection" #> <#@ output extension=".cs" #> <# //relative path to the DLL for your custom assembly in source control var filename = this.Host.ResolvePath("..//..//..//..//BuildAssemblies//BuildTasks.dll"); Version buildInfoAssemblyVersion = AssemblyName.GetAssemblyName(filename).Version; // Setup the version information. Using the DateTime object make it kinda unique var version = new Version(DateTime.Now.Year, DateTime.Now.Month, DateTime.Now.Day, buildInfoAssemblyVersion.Revision + 1); #> using System.Reflection; using System.Runtime.CompilerServices; using System.Runtime.InteropServices; using System.Windows.Markup; // General Information about an assembly is controlled through the following // set of attributes. Change these attribute values to modify the information // associated with an assembly. [assembly: AssemblyTitle("BuildTasks")] [assembly: AssemblyDescription("")] [assembly: AssemblyConfiguration("")] [assembly: AssemblyCompany("Microsoft")] [assembly: AssemblyProduct("BuildTasks")] [assembly: AssemblyCopyright("Copyright © Microsoft 2012")] [assembly: AssemblyTrademark("")] [assembly: AssemblyCulture("")] // Setting ComVisible to false makes the types in this assembly not visible // to COM components. If you need to access a type in this assembly from // COM, set the ComVisible attribute to true on that type. [assembly: ComVisible(false)] // The following GUID is for the ID of the typelib if this project is exposed to COM [assembly: Guid("feab7e26-0830-4e8f-84c1-774268727cbd")] // Version information for an assembly consists of the following four values: // // Major Version // Minor Version // Build Number // Revision // // You can specify all the values or you can default the Build and Revision Numbers // by using the ''*'' as shown below: // [assembly: AssemblyVersion("1.0.*")] // Version information is a combination of DateTime.Now and an incremented revision number coming from the file: // <#= filename #> [assembly: AssemblyVersion("<#= version.ToString() #>")] [assembly: AssemblyFileVersion("<#= version.ToString() #>")] [assembly: XmlnsDefinition("http://localhost/BuildTasks/Activities", "BuildTasks.Activities")] [assembly: XmlnsDefinition("http://localhost/BuildTasks/Activities/InstallerA", "BuildTasks.Activities.InstallerA")] [assembly: XmlnsDefinition("http://localhost/BuildTasks/Activities/InstallerB", "BuildTasks.Activities.InstallerB")] [assembly: XmlnsDefinition("http://localhost/BuildTasks/Activities/CodeAnalysis", "BuildTasks.Activities.CodeAnalysis")] [assembly: XmlnsDefinition("http://localhost/BuildTasks/Activities/Standards", "BuildTasks.Activities.Standards")] [assembly: XmlnsDefinition("http://localhost/BuildTasks/Activities/CI", "BuildTasks.Activities.CI")] [assembly: XmlnsDefinition("http://localhost/BuildTasks/Activities/Version", "BuildTasks.Activities.Version")]

Notará que en la parte inferior también configuro definiciones de espacios de nombres XML para cada uno de los espacios de nombres que uso en el flujo de trabajo. Descubrí que el XMAL generado se ve mucho más limpio y también me ayudó con mis problemas.

Creé este archivo como AssemblyInfo.tt y me aseguro de ejecutarlo (haga clic con el botón derecho y seleccione Ejecutar T4 o algo así) antes de construir el ensamblaje.

Tuve exactamente el mismo problema. La razón era que había compilado la biblioteca con las actividades personalizadas contra la plataforma x86 y el controlador de compilación se estaba ejecutando en una máquina virtual de Windows 2008 de 64 bits. El cambio de la plataforma de destino a AnyCPU permitió que el controlador de compilación utilizara inmediatamente la biblioteca sin tener que agregarla al GAC.