Ошибка пользовательской сборки TFS 2010 TF215097

Для процесса сборки в TFS 2010 я создал библиотеку, содержащую некоторые пользовательские действия с кодом. Раньше все работало нормально, добавляя библиотеку (*.dll) в Source Control и устанавливая "Control Controller - Version Control Path to Custom Assemblies" на путь, в котором библиотека могла быть найдена в Source Control.

Но так как через несколько дней (и я часто обновляю библиотеку) сборка больше не преуспевает. Сообщается об ошибке:

TF215097: Произошла ошибка во время инициализация сборки для сборки определение "Невозможно создать неизвестное type '{clr-namespace: BuildTasks; assembly = BuildTasks}'

После поиска я не нашел другого решения, кроме установки библиотеки в GAC. Это работает, но мне интересно, почему невозможно заставить его работать без необходимости установки в GAC.

Итак, хотя он снова работает, я хотел бы вернуть его, чтобы работать по-старому, без GAC. Надеюсь, некоторые из вас могут мне помочь. Спасибо заранее.

Ответ 1

Так как ответа не дано, и я не нашел никакого исправления, я решил включить в GAC сейчас. Это тоже работает.:)

Ответ 2

Если вы хотите указать сборки, которые содержат пользовательские действия кода, которые вы написали, вам необходимо сделать следующее:

Создайте свои пользовательские действия в ваш рабочий процесс.
Убедитесь, что ваш Определяется xmlns сверху. правильно: XMLNS: локальные = "CLR-пространства имена: BuildTasks; сборка = BuildTasks"
Убедитесь, что теги в XAML для процесс сборки имеет локальный (или любой префикс, который вы использовали) правильно.
Проверьте свой обновленный XAML рабочего процесса в проект вашей команды и обновите определения сборки.
Создайте новый каталог в своем командном проекте под названием "CustomBuildAssemblies"
Перейдите в папку bin/Debug (или release) проекта, которую вы использовали для создания пользовательских задач сборки (в основном получите DLL, которую вы кладете в GAC) и поместите в каталог, созданный на шаге 5.
Сообщите контроллеру сборки, где искать пользовательские сборки, перейдя в Team Exporer, выбрав проект, для которого вы это делаете, разверните список проектов и щелкните правой кнопкой мыши на "Builds" и выберите "Manage Build Controllers", Выделите контроллер (должно быть первым в списке) и нажмите свойства. Установите путь управления версиями к каталогу, который был создан на шаге 5 (находится в середине всплывающего окна).

В этот момент у вас есть собственный рабочий процесс XAML, который ссылается (импортирует) пользовательскую сборку (или несколько), которые были включены в исходный элемент управления. Контроллер сборки теперь знает, где расположены эти пользовательские сборки. Это позволяет вам "проверять" новые версии этих пользовательских сборок, если вам когда-либо понадобится добавлять/обновлять свои пользовательские задачи сборки.

Надеюсь, это поможет вам. Мне понадобилось время, чтобы понять это. Дайте мне знать, если мне нужно сделать это более подробно. Мне хотелось бы опубликовать несколько скриншотов из диалогов.

UPDATE: Я полностью забыл об этой теме, пока не увидел, что она ожила. Я также могу обновить этот ответ, поскольку я нашел очень хороший способ заставить 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 и просто запустил его (щелкните правой кнопкой мыши и выберите запустить T4 или что-то в этом роде), прежде чем создавать сборку.

Ответ 3

Это решение может не относиться ко всем случаям, так как ответы, приведенные в предыдущих сообщениях, являются правильными, но не являются решением моей проблемы. Этот ответ предполагает следующее:

сборки пользовательских решений все изменены и проверены и правильно помечены и построены.
Контроллер сборки был указан в правильном месте управления источником для пользовательских сборок.

Что я и (я подозреваю, многие другие) делают, это копирование или связывание их документов рабочего процесса xaml в решении, чтобы вы могли использовать конструктор рабочего процесса и новые пользовательские сборки. Ну, это отлично работает в дизайнере VS, но VS изменит ваши ссылки на сборки своими собственными. Например, у меня есть ссылка, которая выглядит следующим образом:

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

После редактирования рабочего процесса с моим проектным решением визуальная студия изменила это на:

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

Ответ 4

Этот атрибут вам нужен в вашем классе codeActivity:

В другом месте сборка не загружается.

Ответ 5

Как упоминалось Rhapsody 2 июня 2010 года, GAC может использоваться. Однако следует отметить, что если вы используете GAC, вам нужно остановить и перезапустить службу сборки, чтобы он повторно просматривал GAC, а затем собирал вашу DLL.

Я первоначально зарегистрировал свою DLL в GAC, и когда я выпустил сборку, которая указывала на рабочий процесс, состоящий из моей собственной сборки активности кода, сборка завершилась неудачно. Но после остановки и перезапуска службы сборки сборка не сработает сразу с ужасным "Ошибка при инициализации сборки для определения сборки [BuildDefinitionName]: Невозможно создать неизвестный тип...".

Ответ 6

Это сработало для меня - имя сборки должно быть включено в объявление пространства имен для настраиваемого элемента управления:

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

Ответ 7

Сегодня я не нашел ответа на эту проблему, поэтому, вероятно, этот ответ придет слишком поздно для некоторых из вас.

Я действительно застрял, пытаясь сделать то же самое из GAC, изменив объявление пространства имен, и я всегда находил знаменитый "Не могу создать неизвестный тип" {clr-namespace: bla, bla, bla ". Модификация всех шаблонов сборки каждый раз, когда вы можете добавить новую сборку, является болезненным и раздражающим. Я столкнулся с некоторыми проблемами, установив сборку в GAC, похоже, что есть какой-то кеш, поскольку пользовательские действия не обновлялись, даже если я удалил и переустановил сборку из GAC,

Наконец, я нашел в http://msdn.microsoft.com/en-us/library/ee330987.aspx, что вы можете добавить пользовательские сборки с помощью настраиваемых действий, добавив их в Control Control и установив путь управления для пользовательских сборок в свойствах контроллера сборки (вы можете получить доступ к консоли консоли Team Foundation → Конфигурация сборки → Свойства контроллера)

Вам просто нужно добавить свои сборки в исходный элемент управления, и TFS позаботится обо всем.

Ответ 8

У меня была такая же проблема. Причина заключалась в том, что я скомпилировал библиотеку с пользовательскими действиями против платформы x86, а контроллер сборки был отключен от 64-битной виртуальной машины Windows 2008. Переключение целевой платформы на AnyCPU позволило контроллеру сборки немедленно использовать библиотеку, не добавляя ее в GAC.

Ответ 9

Мне понадобилось исправление частичного определения класса моего класса и применить к нему атрибут BuildActivity. Моя проблема заключалась в том, что у меня отсутствовал атрибут BuildActivity для моего класса активности, так как я реализовал его в свободном Xaml, а не как активность кода, поэтому это исправило его для меня.

Предположительно, Team Build загружает любую сборку, содержащую класс с BuildActivity или BuildExtension, и теоретически это должно привести к тому, что любой класс в сборке будет доступен для сборки. Это позволило бы использовать некий класс загрузочного загрузчика, который позволил бы загружать действия Xaml, не требуя этих определений частичного класса, но на практике это не сработало для меня.

Ответ 10

Проверьте уведомления о событиях Windows. Возможно, ваша DLL пользовательской активности НЕ загружена должным образом.

Если это не так, тогда вам, возможно, придется изменить целевую платформу вашего проекта пользовательских действий... либо на 32-битную, либо на 64-разрядную.

Ответ 11

Атрибут, упомянутый выше:

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

В общем, действительно кажется, что TF215097 может означать, что "вы на что-то сломаны", а не просто "я не мог его найти".

Ответ 12

Другой источник этой ошибки, если вы по ошибке добавляете расширения сборки для разных версий TFS. Например, если вы используете TFS 2012, но попробуйте использовать TFS 2013 build extensions, вы получите эту ошибку.

Ответ 13

У меня не было никакого успеха с другими ответами в этой теме, но я думал, что поделюсь тем, что сделал. Моя пользовательская сборка была загружена на мою машину сборки через GAC. Мне пришлось вручную открыть файл XAML с шаблоном сборки и добавить мою сборку в ссылку пространства имен. По какой-то причине Visual Studio неправильно ссылалась на это для меня.

До:

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

После

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

Моя сборка сборки сборки называется ModifyTasks.dll, замените ее собственным именем файла...

Ответ 14

Я столкнулся с такой же проблемой после перезагрузки нашего сервера сборки 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) предложил удалить исходный путь набора для DLL настраиваемых действий в конфигурации контроллера сборки, сэкономив обновленную конфигурацию, повторное добавление одного и того же пути и сохранение снова.

Это исправило проблему для меня.