Тот же файл MSBuild, разные результаты на локальной машине и CCNet

Question

Фон

Я использую следующее:

• VS 2012
• Приложения.NET 4.5, включая приложение MVC4, приложение C# Domain и проекты NUnit.
• Пользовательский файл MSBuild
• CruiseControl.NET работает на сервере сборки

У меня есть следующие цели сборки:

• Очистить: удаляет каталог buildartifacts
• Init: создает пустой каталог buildartifacts
• Компилировать: компилирует решение
• Test: запускает NUnit Tests
• Пакет: создает пакет ZIP для развертывания
• Развертывание: развертывание пакета на удаленном сервере IIS.

проблема

• Когда я запускаю сборку с локального компьютера, она отлично упаковывается и развертывается.
• Когда CCNet запускает ту же цель сборки, файлы появляются для развертывания

Попытки разрешения / потенциальные возможности

• Я запустил одну и ту же цель в PowerShell с обеих машин и не видел ни ошибок, ни предупреждений.
• Поскольку я говорю CCNEt переопределить инфраструктуру, чтобы она указывала на файлы.NET 4.5, которые я скопировал на сервер сборки, я заставил свою локальную машину указывать на те же файлы при запуске MSBuild, но моя локальная сборка все еще работала и была развернута.
• В Visual Studio я удостоверился, что все файлы содержимого помечены с помощью действия "Создание" "Содержимое" и параметра "Копировать в вывод" "Всегда копировать".

Код

• Доступный в гисте в https://gist.github.com/53ef2a63931d190593f6
• (файл был очищен, имя приложения и учетные данные заменены и т. д.)

Answer 1

Оказывается, это была совершенно не связанная с этим проблема.

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

CCNet получал ошибку subversion, которая не регистрировалась как ошибка. В результате я никогда не получал последнюю версию репозитория, поэтому все файлы были повреждены.

Ошибка связана с этим вопросом Stackru, касающимся ошибки sqlite при попытке использовать tortoisesvn для обновления. Решение в моем случае состояло в том, чтобы просто удалить рабочую копию сервера сборки, воссоздать папку и выполнить проверку svn.