Критическая вещь для понимания здесь - это то, что «конкретная версия» не имеет ничего общего с тем, как приложение ведет себя во время выполнения - это не влияет на способ, с помощью которого среда выполнения .net разрешает сборки.
Все, что касается «конкретной версии», сообщает Visual Studio (а не компилятору), что когда проект загружается в среду IDE, если ссылка на DLL недоступна в разрешенных местах, следует ли принимать другую версию одна и та же DLL. Если в «Специфической версии» установлено значение «ИСТИНА», и вы удалите или удалите некоторую зависимость проекта, Visual Studio поместит небольшой восклицательный знак над этой ссылкой в обозревателе решений. Если для «Специфической версии» установлено значение «ЛОЖЬ», и есть ДРУГИЕ ВЕРСИИ этой доступной DLL (если VS найдет ее), Visual Studio вернется к ссылке на эту DLL. Конечно, это будет проявляться только при следующем построении ... ваш новый вывод будет ссылаться на «резервную DLL».
Получаемый результат тот же, однако - в том, что любая версия DLL, на которую ссылался ваш проект, когда она была скомпилирована, является версией DLL, которая будет НЕОБХОДИМО во время выполнения - она НЕ МОЖЕТ быть заменена другой версией (я, из конечно, ссылаясь только на сильно названные DLL здесь и игнорируя explicitly declared version redirection).
Что это означает для вашего конкретного сценария - это то, что в случае, когда вы НЕ используете определенное управление версиями - вам нужно будет отслеживать зависимости, которые ваш проект имел при их компиляции (таблица Excel: Yuck ...) потому что вы не сможете гарантировать, если вы посмотрите в своем исходном контроле, что версия, на которую ссылается проект, - это тот, который действительно скомпилирован в проект. Конечно, вы должны хранить копии всех двоичных файлов, которые вы выпускаете в дикую природу, чтобы вы могли проверить их, чтобы узнать, что было развернуто для клиента ...
Чтобы ответить на ваш вопрос - нет, вам не нужно развернуть основной проект - вам просто необходимо знать версию этих проектов зависимостей, в то время развернутых их, так что вы можете либо создать совместимые стразы ...
- несовместимый: DLL выглядит так же, извне, те же классы/свойства/методы и т. д.
- hot-fix: сохраняя версию сборки такой же, как в дикой природе) -
... ИЛИ написать новую DLL и выполнить привязку сборки, переадресацию из старой версии в новую.
Спасибо! Что помогает.. – Codex