Стратегия разработки и тестирования SDK, который будет находиться в GAC - PullRequest
1 голос
/ 09 марта 2011

Я разрабатываю SDK для внутреннего использования в нашей компании.Он не будет развернут (в форме SDK, он будет развернут как среда выполнения, включенная в наши продукты) за пределами компании.Другие группы разработки будут использовать этот SDK для разработки продуктов и получат SDK через установку (они не будут извлекать исходный код или двоичные файлы из системы контроля версий).Как часть установки, сборки SDK будут помещены на целевой компьютер, и они также будут установлены в GAC.При развертывании продукта msm «времени выполнения» SDK будет использоваться для установки сборок SDK в GAC.

Таким образом, каждый разработчик установит SDK на свой компьютер.Когда они захотят добавить ссылку, они перейдут к месту установки SDK (или получат его через вкладку .NET в диалоговом окне «Добавить ссылки», если мы решим зарегистрировать сборки).Когда они запускают продукт, который разрабатывают, сборки будут решаться из GAC.

Все это кажется довольно разумным.

Мой вопрос о том, как мне лучше всего, как разработчику SDK, работать.В первую очередь я буду работать над SDK.Поэтому, в дополнение к написанию кода для SDK, я буду писать тестовый код, тестовые приложения, примеры и т. Д. Лучше ли писать тесты для «установленного» SDK (т.е. ссылаться на сборки из их «установленного» расположения,убедитесь, что сборки установлены в GAC, чтобы при выполнении тестов (и т. д.) они разрешались из GAC так же, как в реальной жизни?) Если я буду работать таким образом, то, как я работаю над SDK, если яЧтобы внести изменения, мне нужно убедиться, что измененная сборка находится в GAC.

В дополнение к работе с SDK я могу также внести вклад в реальные функции продукта, которые, в свою очередь, могут использовать функциональность вSDK.Опять же, мне кажется, что я должен выполнить свою работу с «установленным» SDK, чтобы я использовал ту же версию, что и все остальные.

Может быть, я слишком усложняю это, но я чувствую некоторую растерянность по всей проблемеуправления работой, выполняемой (мной) локально в SDK, запуском / тестированием по отношению к «развернутым» сборкам (GAC) и как / если переходить между ними.Часть моей проблемы заключается в том, что у меня большой опыт разработки приложений, работающих над «большими» проектами, где мне не приходилось сталкиваться с такими проблемами (развертывание, сборка и т. Д.).То есть я всегда был потребителем любых SDK, разработанных внутри компании, а не производителем (или производителем / потребителем).Я также только недавно перешел с C ++ / COM / VB6 на .NET разработки.Что бы это ни стоило, я буду разрабатывать в основном на C # и буду разрабатывать (или вносить вклад) в библиотеки классов и службы WCF.

Я нашел эту ссылку здесь, в SO, о проблемах тестирования при работе с развернутым GACсборки:

Тестирование кода в развернутых сборках GAC

Но я не уверен, что это мне очень помогло.

В любом случае, спасибо за любыеСоветы или идеи, которыми может поделиться каждый.

1 Ответ

4 голосов
/ 10 марта 2011

Ты слишком усложняешь дела. Нет никакой функциональной разницы между загрузкой сборок из локального каталога bin приложения и загрузкой из GAC. Для модульного тестирования используйте самое простое и быстрое решение: просто запустите тесты, ссылающиеся на сборки SDK, которые были скопированы в локальный каталог bin тестового приложения в процессе сборки.

У вас должен быть другой шаг тестирования, который выполняет загрузку приложения, которое ссылается на ваши SDK, которые находятся в GAC, чтобы убедиться, что у вас нет проблем с подписью, но это скорее общесистемный интеграционный тест, который должен быть запустить перед выпуском и после любых изменений конфигурации установки. Так как шансы испортить вашу установку GAC относительно невелики, ее не нужно постоянно контролировать, ИМО.

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

...