В TFS 2010 Пользовательское действие ошибка построения TF215097
для процесса сборки в TFS 2010 я создал библиотеку, содержащую некоторые действия пользовательского кода. В прошлом все это отлично работало, добавляя библиотеку (*.dll) для управления версиями и установки "Build Controller - Version Control Path to Custom Assemblies" в путь, где библиотека может быть найдена в системе управления версиями.
но с нескольких дней (и я часто обновляю библиотеку) сборка больше не удается. Сообщение об ошибке:
TF215097: произошла ошибка инициализация построения для построения определение "невозможно создать неизвестный введите ' {clr-namespace:BuildTasks; assembly=BuildTasks}'"
после поиск Я не мог найти другого решения, кроме установки библиотеки в GAC. Это работает, но мне интересно, почему невозможно заставить его работать без необходимости установки в GAC.
поэтому, хотя он снова работает сейчас, я хотел бы вернуть его на работу старый путь, без GAC. Надеюсь, кто-нибудь из вас сможет мне помочь. Спасибо заранее.
14 ответов
Если вы хотите указать сборки, содержащие написанные вами действия пользовательского кода, вам необходимо сделать следующее:
- создайте пользовательские действия в ваш рабочий процесс.
- убедитесь, что ваш xmlns в верхней части определяется правильно: xmlns: local= "clr-пространство имен: BuildTasks; assembly=BuildTasks"
- убедитесь, что теги в XAML для процесс сборки имеет локальный (или какой префикс вы использовали) правильно.
- Проверьте обновленное workflow XAML в командный проект и обновите определения сборки.
- создайте новый каталог в командном проекте под названием "CustomBuildAssemblies"
- перейдите в папку bin/Debug (или release) проекта, который вы использовали для создания пользовательских задач сборки (в основном получите dll, которую вы помещаете в GAC), и поместите ее в каталог, созданный на шаге 5.
- сообщите контроллеру сборки, где искать пользовательские сборки, перейдя в Team Exporer, выбрав проект, для которого вы это делаете, разверните список проектов и щелкните правой кнопкой мыши на " сборки "и выберите"Управление контроллерами сборки". Выберите контроллер (должен быть первым в списке) и нажмите "Свойства". Задайте путь управления версиями к каталогу, который был создан на шаге 5 (расположен в середине всплывающего окна).
на данный момент у вас есть пользовательский рабочий процесс XAML, который ссылается (импортирует) пользовательскую сборку (или несколько), которые были включены в систему управления версиями. Контроллер сборки теперь знает, где находятся эти пользовательские сборки. Это позволяет вам "проверять" новые версии этих пользовательских сборок, если вам когда-либо понадобится добавить/обновить пользовательские задачи сборки.
надеюсь, это поможет вам. Мне тоже потребовалось некоторое время, чтобы понять это. Дай мне знать, если мне понадобится сделать это более детальным. Хотел бы я опубликовать скриншоты диалогов.
обновление: Я совсем забыл об этом нить, пока я не увидел, что она ожила. Я также могу обновить этот ответ, поскольку я нашел очень хороший способ заставить TFS вытащить последнюю версию сборки пользовательских задач сборки: создание уникального номера версии для сборки.
Я использую шаблон T4 и запускаю его перед сборкой. Он обновляет AssemblyInfo.cs после чтения зарегистрированной пользовательской библиотеки DLL активности.
<#@ 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")]
вы заметите, что внизу я также устанавливаю определения пространства имен XML для каждого из пространств имен который я использую в рабочем процессе. Я обнаружил, что сгенерированный XMAL выглядит намного чище, и это также помогло с моими вопросами.
Я создал этот файл как AssemblyInfo.tt и просто убедитесь, что я запустил его (щелкните правой кнопкой мыши и выберите run T4 или что-то в этом роде) перед сборкой.
Это решение может применяться не ко всем случаям, поскольку ответы, представленные в предыдущих сообщениях, верны, но не были решением моей проблемы. Этот ответ предполагает следующее:
- пользовательские сборки решений все изменены в checked in и правильно помечены и построены.
- контроллер сборки был указан в правильном месте управления версиями для пользовательских сборок.
что я и(я подозреваю, многие другие) делают это копирование или связывание документов рабочего процесса xaml в решение, чтобы можно было использовать конструктор рабочих процессов и новые пользовательские сборки. Ну, это отлично работает в VS designer,но VS изменит ваши ссылки на сборки своими собственными. Например у меня есть ссылка, которая выглядит следующим образом:
xmlns:ca="clr-namespace:Custom.TFS.Activities;assembly=Custom.TFS.Activities"
после редактирования рабочего процесса с помощью моего решения проекта visual studio изменила это на:
xmlns:local="clr-namespace:Custom.TFS.Activities"
когда вы проверяете этот файл для тестирования или использования, теперь вы увидите страшная ошибка TF215097.
добавлять ;assembly=your.assembly
должен устранить проблему и удалить необходимость поместить все в GAC. Также может потребоваться исправить ссылки на пространство имен, используемые в остальной части файла xaml.
БОЛЬШОЕ СПАСИБО: http://msmvps.com/blogs/rfennell/archive/2010/03/08/lessons-learnt-building-a-custom-activity-to-run-typemock-isolator-in-vs2010-team-build.aspx
Как упоминалось рапсодией 2 июня 2010 года, GAC можно использовать. Однако следует отметить, что если вы используете GAC, вам нужно остановить и перезапустить службу сборки, чтобы она повторно сканировала GAC, следовательно, забирая вашу DLL.
Я изначально зарегистрировал свою DLL в GAC, и когда я запустил сборку, которая указывала на рабочий процесс, состоящий из моей сборки действия пользовательского кода, сборка не удалась. Но после остановки и перезапуска службы сборки, Сборка не подведет сразу с ужасным " произошла ошибка при инициализации сборки для определения сборки [BuildDefinitionName]: невозможно создать неизвестный тип...".
Это работает для меня -- имя сборки должно быть включено в объявление пространства имен для пользовательского элемента управления:
Я не нашел ответа на эту проблему, поэтому, наверное, этот ответ будет приехать слишком поздно для некоторых из вас.
Я действительно застрял, пытаясь сделать то же самое из GAC, изменяя объявление пространства имен,и я всегда находил знаменитый "не могу создать неизвестный тип"{clr-namespace:bla,bla, bla". Изменение всех шаблонов сборки каждый раз, когда вы можете добавить новую сборку, является болезненным и раздражающим опытом. Я испытал некоторые проблемы, установив сборку в GAC, похоже, там это какой-то кэш, потому что пользовательские действия не были обновлены, даже если я удалил и переустановил сборку из GAC,
наконец, я нашел в http://msdn.microsoft.com/en-us/library/ee330987.aspx что можно добавить пользовательские сборки с пользовательскими деятельности путем добавления их в систему управления и контроля параметров пути для пользовательских сборок на сборки контроллера свойствами (можно получить доступ из команды фонда администрации консоль --> конфигурация --> контроллер Свойства)
вам просто нужно добавить свои сборки в систему управления версиями, и TFS позаботится обо всем.
У меня была точно такая же проблема. Причина заключалась в том, что я скомпилировал библиотеку с пользовательскими действиями на платформе x86, а контроллер сборки запускал 64-разрядную виртуальную машину Windows 2008. Переключение целевой платформы на AnyCPU позволило контроллеру сборки немедленно использовать библиотеку без необходимости добавлять ее в GAC.
Мне нужно было создать частичное определение класса моего класса и применить к нему атрибут BuildActivity. Моя проблема заключалась в том, что мне не хватало атрибута BuildActivity в моем классе activity, так как я реализовал его в свободном Xaml, а не как действие кода, поэтому это исправило его для меня.
предположительно, Team Build загружает любую сборку, содержащую класс с BuildActivity или BuildExtension на нем, и теоретически это должно привести к тому, что любой класс в указанной сборке доступно для сборки. Это позволило бы создать своего рода фиктивный класс загрузчика, который позволил бы загружать действия Xaml без необходимости этих частичных определений классов, но на практике это не сработало для меня.
Проверьте уведомления о событиях Windows. Возможно, ваша пользовательская DLL активности не загружена должным образом.
Если это не так, то вам может потребоваться изменить целевую платформу вашего пользовательского проекта активности... либо 32 бит или 64 бит.
поскольку никакого ответа не дано, и я не нашел никакого исправления, я решил положить в GAC сейчас. Это тоже работает. :)
атрибут, упомянутый выше:
Microsoft.TeamFoundation.Build.Client.BuildActivity( Microsoft.TeamFoundation.Build.Client.HostEnvironmentOption.Agent )
В общем, кажется, что TF215097 может означать ,что" ты сломан", а не просто"я не мог его найти".
еще один источник этой ошибки, если вы по ошибке смешиваете расширения сборки для разных версий TFS. Например, если вы используете TFS 2012, но пытаетесь использовать расширения сборки TFS 2013 вы получите эту ошибку.
у меня не было успеха с другими ответами в этой теме, однако я думал, что поделюсь тем, что я сделал. Моя пользовательская сборка была загружена на мою машину сборки через GAC. Мне пришлось вручную открыть файл XAML шаблона сборки и добавить мою сборку в ссылку на пространство имен. По какой-то причине Visual Studio неправильно ссылалась на это для меня.
перед:
xmlns:ba1="clr-namespace:BuildTasks.Activities"
после
xmlns:ba1="clr-namespace:BuildTasks.Activities;assembly=ModifyTasks"
моя сборка задачи пользовательской сборки называется ModifyTasks.файл DLL замените его собственным именем файла...
Я столкнулся с той же проблемой после перезагрузки нашего сервера сборки TFS 2012. Работа CI, которая работала отлично, перестала работать с упомянутой ошибкой TF215097, она не смогла найти пользовательскую активность.
комментарий на этой странице (https://social.msdn.microsoft.com/Forums/vstudio/en-US/479449e1-5c02-4744-b620-3bba64038cef/custom-build-activity-tf215097-cannot-create-unknown-type?forum=tfsbuild) предложено удалить путь источника set к пользовательскому действие DLL в конфигурации контроллера сборки, сохранение обновленной конфигурации, повторное добавление того же пути и сохранение снова.
это исправило проблему для меня.