Как мне обработать две сборки с одним и тем же именем файла во время сборки TFS 2010 RC?

Question

Я следую шаблону CSLA.NET для Silverlight, использующему то же имя файла для сборок бизнес-объектов. Например:

CSLA.dll               // .NET assembly
MyProject.Entities.dll // .NET assembly
CSLA.dll               // Silverlight assembly
MyProject.Entities.dll // Silverlight assembly

Это сделано для того, чтобы вы могли использовать один файл кода в проекте .NET, «связать файл» с проектом Silverlight, и обе сборки использовали один и тот же код (при необходимости компилируя .NET и Silverlight функционально).

Причина одинаковых имен файлов ассемблера заключается в том, что привязки сериализации WCF просто автоматически работают.

Проблема, с которой я столкнулся, заключается в том, что мой сервер сборки, похоже, помещает обе сборки в один и тот же выходной каталог (папка Binaries на сервере сборки) и использует этот каталог для разрешения ссылок на проекты, но получает неправильный файл один Silverlight вместо .NET один).

Кто-нибудь знает, как справиться с этой ситуацией?

EDIT:

Я использую TFS 2010 Beta2, VS 2010 RC1, Build Agent 2010 RC1

Answer 1

Аарон Холлберг упомянул мне, что вы можете изменить действие MSBuild в рабочем процессе, чтобы не устанавливать OutDir. Это сработало, но заставило папку Binaries не получить копию вывода.

Вместо этого я создал три конфигурации сборки в решении: ClrOnly, SilverlightOnly и WebsiteOnly. Затем на вкладке «Процесс» в определении сборки я установил «Элементы» для сборки «1 project(s) and 3 configuration(s)». Теперь вывод Binaries выглядит следующим образом:

Nightly_20100217.1\
                  \Multi Platform\
                                 \ClrOnly
                                 \SilverlightOnly
                                 \WebsiteOnly\
                                             \_Published Sites

А мои юнит-тесты и все отлично работают.

РЕДАКТИРОВАТЬ:

Опубликованный веб-сайт, с другой стороны, является недействительным, поскольку при сборке и публикации он выбирает неправильные ссылки.

Answer 2

Стратегия, которую я использовал в прошлом, состоит в том, чтобы использовать один и тот же исходный каталог для обоих проектов и вложить файлы, специфичные для платформы, в дискретно именованные подкаталоги и то же самое для выходных данных, например. bin \ debug \ clr и bin \ debug \ sl. Это требует небольшого ручного редактирования файлов проекта, но, похоже, работает хорошо. Я не помню, чтобы у меня были проблемы с сервером сборки. но я могу ошибаться.