Как я могу исправить сборки .NET?

Если я скомпилирую проект C # дважды, я получу две сборки. Эти сборки не совсем одинаковы (с использованием бинарного сравнения). Я могу думать о причинах, почему это так, но факт остается фактом, что источник для двух сборок идентичен.

Я заинтересован в создании патча между этими сборками и применении патча на клиентском компьютере.

Кто-нибудь знает библиотеку (желательно .NET) или инструмент, с помощью которого я могу создавать и применять патчи?

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

Обновить:

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

Это приводит к изменению ссылок на сборки при создании приложения, но я доволен этим. Сейчас я занимаюсь распространением обновления до ранее выпущенной версии. Я строю обновления с помощью InstallShield. Сборки, доступные для InstallShield, уменьшены до небольших исправлений. Это не сильно увеличивает размер обновления.

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

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

 MartinStettner17 авг. 2009 г., 23:08
Хм, если источник один и тот же, зачем вам менять сборку на клиентском компьютере? Просто убедитесь, что номер версии остается тем же (без «*» в атрибуте AssemblyVersion!), Тогда «старая» сборка также будет пригодна для использования ...
 Christo18 авг. 2009 г., 08:33
Cheeso: Да, хорошо заметили, но мне ничего не сказал бы маленький гугл.
 Cheeso17 авг. 2009 г., 18:22
Кроме того, почему вы хотите исправлять сборки для "небольших изменений" и почему можно заменить их на "большие изменения"? Почему бы просто не использовать одну процедуру обновления: заменить сборку.
 Cheeso17 авг. 2009 г., 18:20
Отметка времени включена в скомпилированную сборку. Вот почему он меняется каждый раз, когда вы компилируете.

Ответы на вопрос(2)

Решение Вопроса

http://www.tibed.net/vpatch/

Я использовал его для игр и карт e.t.c. но он должен работать с любыми двумя файлами.

 Christo17 авг. 2009 г., 18:15
Я посмотрю и посмотрю, будет ли это то, что мне нужно. Спасибо!
 Christo18 авг. 2009 г., 11:47
Я посмотрел на vpatch. Это работает даже лучше, чем я ожидал, и будет работать отлично. Еще раз спасибо!

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

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

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

 Christo18 авг. 2009 г., 08:36
Почему бы не исправить это? Если ссылки изменились, это может оказать небольшое влияние, но правильное исправление преобразует сборку A в B и включает только необходимые биты для изменения ссылок сборки в A.
 Cyril Gupta17 авг. 2009 г., 18:16
+1 за добрый, дельный совет.
 Reed Copsey18 авг. 2009 г., 17:29
Много лет попыток исправления программного обеспечения на местах устали от любого решения по исправлению. И моя компания, и поставщики, которых мы использовали, шли по этому пути, и в обязательном порядке обнаружили, что это в лучшем случае проблематично. Это работает, в большинстве случаев, но когда есть проблема, это ужасно трудно исправить. Очень сложно сделать все, что может сделать правильная установка из патча, а пропускная способность для загрузки обновлений стоит дешево. Исправление просто не стоит усилий.

Ваш ответ на вопрос