Visual Studio.net DLL проблемы со ссылками

Question

У нас есть несколько c # проектов, библиотек и решений (несколько приложений asp.net, несколько библиотек классов, приложений Windows, таких как службы Windows, приложения Winform и т. Д.), Большинство из которых зависит от выходных библиотек друг друга. Некоторые из наших проектов сгруппированы в решения и используют зависимость проекта. Но некоторые проекты не являются. Мы (к сожалению) используем VSS для управления источником. При ссылке на сборки в проекте иногда я вижу файлы обновлений, сохраненные в vss, но фактическая dll никогда не появляется, когда вы изначально получаете последнюю версию, иногда только сборки, но не vss, иногда просто сборки, и они, похоже, управляются vss. Как вы можете догадаться, управлять этими файлами для нас - кошмар, особенно при публикации веб-приложений. Мы никогда не уверены, что последние версии библиотечных библиотек публикуются. Можете ли вы посоветовать какие-либо лучшие практики по управлению этой сложностью? Любые статьи тоже приветствуются. Должны ли мы хранить все библиотеки в сетевой папке и использовать файлы обновления? Таким образом, каждый разработчик в команде должен скопировать свой выходной файл в эту сетевую папку?

Спасибо, Умут

Answer 1

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

Таким образом, если DLL когда-либо обновляется, это так же просто, как «Извлечь - перезаписать - проверить», и все члены команды могут получить последний файл.

И, кроме того, это облегчает развертывание, так как файлы включаются во время публикации. Просто установите тип сборки на контент.

Answer 2

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

Более сложным и менее ручным подходом было бы реализовать некоторую форму автоматизации сборки. Я бы посоветовал взглянуть на MSBuild (http://msdn.microsoft.com/en-us/library/0k6kkbsd.aspx),, который использует XML-файлы как своего рода язык сценариев. Загрузите пакет Community Tasks (также http://msbuildtasks.tigris.org/)). С этими двумя инструментами вы сможете для создания файла MSBuild, который получает ваши различные решения из SourceSafe, а затем создает их (обратите внимание, что вы можете вызвать файл MSBuild из файла MSBuild. Также обратите внимание, что файл решения Visual Studio представляет собой файл MSBuild - вы можете просто использовать свой скрипт MSBuild запустите сборку, которую ваши разработчики создавали в Visual Studio.) После этого вы можете развернуть результат в любом месте.