Ошибка пользовательской сборки TFS 2010 TF215097 - PullRequest
16 голосов
/ 26 мая 2010

Для процесса сборки в TFS 2010 я создал библиотеку, содержащую некоторые пользовательские действия кода. Раньше все работало нормально, добавляя библиотеку (* .dll) в Source Control и устанавливая «Build Controller - Путь управления версиями для пользовательских сборок» по пути, по которому можно найти библиотеку в Source Control.

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

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

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

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

Ответы [ 14 ]

9 голосов
/ 21 июля 2010

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

  1. Создайте свои собственные действия в ваш рабочий процесс.
  2. Убедитесь, что ваш xmlns вверху определяется правильно: XMLNS: локальные = "CLR-пространств имен: BuildTasks; сборка = BuildTasks"
  3. Убедитесь, что теги в XAML для процесс сборки есть локальный (или какой бы префикс вы не использовали) правильно.
  4. Проверьте ваш обновленный рабочий процесс XAML в командном проекте и обновите определения сборки.
  5. Создайте новый каталог в вашем командном проекте под названием «CustomBuildAssemblies»
  6. Перейдите в папку bin / Debug (или release) проекта, который вы использовали для создания пользовательских задач сборки (в основном получите dll, который вы помещаете в GAC), и поместите его в каталог, созданный на шаге 5 .
  7. Сообщите контроллеру сборки, где искать пользовательские сборки, перейдя в Team Exporer, выбрав проект, для которого вы это делаете, разверните список проектов, щелкните правой кнопкой мыши «Сборки» и выберите «Управление контроллерами сборки». , Выберите контроллер (должен быть первым в списке) и нажмите свойства. Задайте путь управления версиями для каталога, который был создан на шаге 5 (находится в середине всплывающего окна).

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

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

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

Я использую шаблон T4 и запускаю его перед сборкой сборки. Он обновляет AssemblyInfo.cs после прочтения зарегистрированной библиотеки пользовательских действий.

<#@ 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 или что-то в этом роде) перед сборкой сборки.

8 голосов
/ 11 ноября 2011

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

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

То, что я и (я подозреваю, многие другие) делают, копируют или связывают свои документы рабочих процессов xaml в решение, чтобы вы могли использовать конструктор рабочих процессов и новые пользовательские сборки. Что ж, это прекрасно работает в конструкторе VS, но 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

6 голосов
/ 19 августа 2010

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

_

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

2 голосов
/ 02 ноября 2011

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

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

1 голос
/ 02 августа 2012

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

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

1 голос
/ 01 июня 2012

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

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

1 голос
/ 20 января 2012

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

1 голос
/ 16 декабря 2010

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

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

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

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

1 голос
/ 22 июня 2010

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

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

0 голосов
/ 21 ноября 2014

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

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

...