2008-09-30 4 views
4

Мы создали собственное приложение для внутреннего использования, которое обращается к TFS. Для этого мы используем библиотеки Microsoft (например, Microsoft.TeamFoundation.dll).C# Пользовательские приложения, которые получают доступ к TFS

Когда это приложение развертывается на ПК, на которых уже установлен Team Explorer или VS, все в порядке. Когда он развертывается на ПК, у которых нет установленного, он терпит неудачу.

Включает в себя все необходимые библиотеки DLL, но ошибка, которую мы получаем, - «Обнаружен общий язык Runtime и недействительная программа». Ошибка возникает на умеренно безобидные линии:

TeamFoundationServer myServer = new TeamFoundationServer(“ourserver.ourdomain.com”); 

Интересно популярный инструмент TFSAdmin (когда вы падаете в необходимых библиотек DLL в каталог EXE) дает ту же ошибку.

Я также отмечаю, что многие другие пользовательские приложения, которые обращаются к TFS (например, http://hinshelwood.com/tfsstickybuddy.aspx), также требуют установки Team Explorer или VS для работы.

Понятно, что библиотек DLL недостаточно и есть какая-то магия, которая возникает, когда происходят эти установки. Кто-нибудь знает, что это? Кто-нибудь знает, как сделать магию?

+0

Вы уверены, что в клиентских сборках TFS нет внешних учетных записей, которые не включены, или они не блокируются системой безопасности Windows? – 2008-09-30 04:00:02

ответ

9

«Официально поддерживаемый» способ записи приложения, использующего объектную модель TFS, состоит в том, чтобы на этом компьютере был установлен Team Explorer. Это особенно важно для обслуживания - то есть, убедитесь, что, когда пакет обновления для VSTS применяется к клиентской машине, тогда также обновляется API TFS. Нет прав перераспределения для API TFS, поэтому они не должны поставляться с вашим приложением.

BTW - Также обратите внимание, что если вы пишете приложение, использующее TFS OM, то обязательно скомпилируйте его как «X86», а не «Любой процессор». Все сборки TFS API отмечены как X86, но если приложение помечено как «Любой процессор», то на машине x64 он будет загружен 64-битным CLR, но когда придет время для динамической загрузки сборок TFS, он не сработает.

Удача,

Martin.

+2

Обратите внимание, что код с использованием объектной модели TFS 2010 больше не нужно компилировать как X86, поскольку API 2010 теперь работает с обеими версиями CLR. – 2010-03-26 20:54:34