Ссылки на сборку не будут корректно разрешены на нашем сервере сборки.

Мы используем код С# с использованием VS2008 SP1. У нас есть сервер, на котором работает Team System Server 2008, который мы используем для управления версиями, задач и т.д. сервер также является нашей машиной для сборки Team Build. Это работает очень хорошо в течение длительного времени. До сих пор. Мы получаем эти сообщения об ошибках при попытке создать один из наших проектов с ссылкой на одну внешнюю сборку (это происходит как с помощью Team Build, и при входе в систему физически и регулярной сборки через Visual Studio):

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

Собрания Syncfusion относятся к стороннему пакету компонентов. Остальные два относятся к компоненту Microsoft ReportViewer.

Ссылки добавлены через окно "Добавить ссылку" на вкладке .NET, поэтому я не думаю, что в этом есть что-то подозрительное. В окне свойств ссылки на сборку нет значения в "Культуре", "Описание", "Путь", "Время выполнения" или "Сильное имя". Версия говорит 0.0.0.0, а Resolved - False. Я думаю, это довольно очевидно, что VS can not разрешает ссылку. Мой вопрос: почему??? Я поцарапал себе голову над этим. Это происходит только на сервере, решение просто отлично работает как на моей машине, так и на моей машине. Ссылочные свойства сборки отлично подходят для наших машин.

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

Обновление 16.02.2009:
Я попытался сравнить вывод ildasm из dll на моем компьютере и на сервере (см. Комментарий, который я написал об этом), и есть одна небольшая разница в строке, которая мне кажется комментарий. Должен признаться, что я не понимаю, почему существует разница, так что, может быть, кто-то может объяснить это мне? Я также попробовал запустить проверку на вирусы на сервере. Не помогло. Попробовал удалить ссылку , а затем readd, просмотрев DLL на диске. Не работает.

Обновление 17.03.2009:
Я нашел решение! Преступником был модуль TruPrevent Panda Антивирус, После отключения модуля все работает! =)
Я обнаружил это с помощью fuslogvw.exe и созданного журнала. Поделился результатами и наткнулся на эту запись в блоге.. Надеюсь, это поможет кому-то другому.

Ответы

Ответ 1

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

Некоторые идеи...

(i) Попробуйте отключить средства защиты от вирусов и вредоносных программ. Я видел случаи, когда эти инструменты (в частности, Trend Micro Antivirus, по какой-то причине) могут сохранять файл DLL заблокированным после (во время?) сканирования, вмешиваться с компиляторами.

(ii) Проверьте переменную среды PATH. Даже в эти современные времена переменная PATH используется для решения некоторых задач - если это испорчено (слишком длинная, максимальная длина - 2048 символов IIRC), тогда все может быть нечетным.

(iii) Вы проверили разрешения файлов - вы проверяли разрешения в реестре? Например, SyncFusion устанавливает свой лицензионный ключ как в ульях пользователя, так и в машине - если сервер сборки не может читать один или другой, могут возникнуть проблемы.

Удачи!

Ответ 2

Также может быть, что ссылочные сборки находятся в GAC на машине dev, но не на машине сборки. Вытащите его из GAC в исходный репозиторий и укажите его по пути.

Ответ 3

У нас была такая же проблема, оказалось, что накопитель C был заполнен (всего 28 МБ).
Освобождение пространства разрешило проблему, хотя сборка происходит на D.

Ответ 4

Вы видите различия между ildasm этого файла

'C:\Program Files\Syncfusion\Essential Studio\7.1.0.21\Assemblies\3.5\Syncfusion.XlsIO.Base.dll'

на вашем компьютере или на сервере?

Ответ 5

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

Ответ 6

Ваша сторонняя dll может зависеть от неуправляемых DLL. Часто это происходит из-за отсутствия конкретной версии VС++ Runtime Dll.

Откройте Dll с помощью Walker Dependency http://www.dependencywalker.com/ на вашем сервере и проверьте отсутствие ссылок.

Ответ 7

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