Как развернуть DLL, которая постоянно меняется?

Question

Я создал несколько небольших приложений, использующих мою собственную DLL. Проблема в том, что эта DLL постоянно меняется. Мое текущее решение этой проблемы состоит в том, что у меня есть проект установки в решении библиотеки классов, который создает и регистрирует DLL. Во всех моих приложениях я должен открыть решение и заново сослаться на вновь созданную / зарегистрированную DLL. Затем Я должен заново скомпилировать их проекты установки, удалить старые приложения, а затем заново установить новое приложение.

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

Я понимаю, что как только DLL создается и используется в приложении, ее практически не следует трогать. У меня нет такой возможности в этой ситуации. Он постоянно обновляется. Готово.

Итак, есть ли лучший способ? Точка в направлении руководства или соответствующего вопроса / ответа / форума будет принята с благодарностью.

Редактировать : DLL не постоянно меняется во время выполнения, но постоянно развивается, чтобы обеспечить больше функциональности и детализации в других приложениях. Кроме того, одна важная вещь, которую я должен был упомянуть, это то, что интерфейс Public постоянно меняется - обычно добавляются новые методы.

Answer 1

Убедитесь, что ссылки на вашу DLL указывают SpecificVersion = false. Затем просто разверните каждую новую версию в GAC, и это должно сработать. В конце концов, вы также можете вручную принудительно установить версии, используя Binding Redirection .

Answer 2

Решение, которое вы можете попробовать, состоит в том, чтобы использовать одно решение для вашего проекта и ссылаться на проект, куда бы он ни шел.

Answer 3

Одно из решений выглядит следующим образом:

• Физически отделить интерфейс от реализации. например AssemblyA - это интерфейс, приложение (скажем AssemblyB) знает только интерфейс во время компиляции. Реализация (AssemblyC) также знает / ссылается на AssemblyA, конечно. Дело в том, что AssemblyB не ссылается на AssemblyC. Это потребует от вас использования контейнера IoC (например, MS Unity 2.0, но есть много других), чтобы разрешать и создавать экземпляры ваших бетонов во время выполнения.
• Напишите процесс обновления, который находит новый файл AssemblyC.dll, заменяет локальную копию и использует отражение вместе с IoCContainer для «загрузки» новой реализации с любым интервалом, который вам требуется, обычно при запуске приложения.

Вышеуказанное зависит от стабильности вашего интерфейса. Если это не так, вы можете написать (более) стабильный фасад .

Answer 4

Выезд NuGet

Вы можете настроить внутренний репозиторий Nuget (на самом деле это просто папка, в которой хранятся файлы nupkg.) Затем, когда вы создаете новую DLL, вы можете обновлять приложения по мере необходимости в студии. Это гарантировало бы, что у него была последняя версия. Они не должны нуждаться в повторном развертывании, если в DLL, которую вы исправляете, нет ошибок.