Исправление приложения .NET

Question

Сегодня я отлаживал проблему, с которой у клиента был удаленный доступ, и вместо того, чтобы создать новую установку и отправить ее ему, я просто скомпилировал dll, убедился, что информация о версии идентична той, которую он установил, и заменилстарый dll с тем, который я только что построил на его машине (на всякий случай подкрепил другой), и все, казалось, все еще работало нормально, с дополнительным преимуществом более подробного ведения журнала, которое я и добавил.

У меня такой вопрос: так ли вообще работает исправление программного обеспечения?Или то, что я сделал, очень опасно?Если это плохой способ, каков будет лучший способ исправления нашего программного обеспечения для исправлений ошибок в будущем?

Answer 1

Идея исправления заключается в том, чтобы изменить существующую установку продукта.Как вы это делаете: замена файлов, применение бинарных различий и т. Д. Не важны.

Как вы сделали обновление, все в порядке;кроме того, что это не масштабируется.Если информация о версии одинакова, вам нужно вручную отследить, какие двоичные файлы установлены вашим клиентом, вместо того, чтобы записывать их в диалоговом окне «О программе».

Кроме того, во многих архивах сборок магазинов разработок отправляютсяклиенту, и как вы архивируете эту конфигурацию?

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

Answer 2

Нет, это неплохо - на самом деле библиотеки DLL должны работать таким образом.Пока вы не сломали ABI или API (вы просто добавили ведение журнала, это здорово), вы сможете заменить содержимое и перезапустить программу.

Кроме того, с юридической точки зрения,LGPL не будет работать без этого.(Одно из положений лицензии заключается в том, что пользователь может заменить вашу копию библиотеки той, которую он создает / предоставляет / находит.)

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

Answer 3

Некоторые номера версий состоят из четырех частей:

Major, Minor, Build и Revision.

Revision будет использоваться для обновлений продукта, исправляющих исправления безопасности или другие серьезные проблемы,Firefox был бы одним из примеров.

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

Answer 4

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

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