Здравствуйте, HotDog, Вы писали:

у соседей-немерлистов именно таким способом который вам нужен, обновляется бутстрап
там используется Ildasm

заодно и в билд-процесс встроили

Здравствуйте, HotDog, Вы писали:

HD>Обрисую еще раз ситуацию в целом. Есть solution состоящее из ~25 csprj. Csprj имеют некоторые зависимости друг от друга.
HD>С течением времени баги фискятся в любом из этих проектов. Теперь принимается решение выпустить "Bugfix" который содержит только измененные assemblies. Вопрос в том как найти эти измененые assemblies? Бинарное сравнение показвает что изменились все файлы.

Почему бы не использовать http://blogs.msdn.com/b/jmstall/archive/2006/11/07/binary-diff.aspx ?

Здравствуйте, HotDog, Вы писали:

HD>VS 2010, компилируем в Release одно и то же assembly два раза.
HD>Сравниваем результаты в бинарном формате "fc /b ..." и видим что есть различия в бинарниках.

HD>Т.е. построить точно такой же проект невозможно из одних и тех же исходных кодов?
HD>Каким образом можно построить "интеллектуальный" diff для апдейта приложения?
HD>Есть какие то приложения, которые по умному определяют, что есть действительно изменения в assembly?

Не надо никакого "по умному". Просто надо хранить артефакты. Выпустили версию N, положили в репозиторий. Выпустили версию N + 1, положили в репозиторий и делайте diff сколько хотите раз.

Здравствуйте, HotDog, Вы писали:

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

Почему тогда при каждом чекине не обновлять версию сборки и отправлять клиенту только те, что больше заданной?

Здравствуйте, HotDog, Вы писали:

HD>Аргументирует это тем, что все работает так как оно сейчас есть.
HD>И переделывать клиентский софт, чтобы решить какие то внутренние, серверные проблемы — плохое решение
Скажи клиенту, что нужно оптимизировать общую сложность решения задачи.
Ибо простые изменения на клиенте и сервере это лучше чем нетронутый клиент и тонна геморроя и костылей на сервере.

VS 2010, компилируем в Release одно и то же assembly два раза.
Сравниваем результаты в бинарном формате "fc /b ..." и видим что есть различия в бинарниках.

Т.е. построить точно такой же проект невозможно из одних и тех же исходных кодов?
Каким образом можно построить "интеллектуальный" diff для апдейта приложения?
Есть какие то приложения, которые по умному определяют, что есть действительно изменения в assembly?

HD>>VS 2010, компилируем в Release одно и то же assembly два раза.
HD>>Сравниваем результаты в бинарном формате "fc /b ..." и видим что есть различия в бинарниках.

GIV>Не надо никакого "по умному". Просто надо хранить артефакты. Выпустили версию N, положили в репозиторий. Выпустили версию N + 1, положили в репозиторий и делайте diff сколько хотите раз.

Что значит "положили в репозитарий"? Положили исходники или положили откомпилированные бинарники?
Исходники и так в репозитории. Бинарники бесполезно зачекивать ибо каждая "N+1" версия оличается от N, хотя копилируются из одних и тех же исходников.

Обрисую еще раз ситуацию в целом. Есть solution состоящее из ~25 csprj. Csprj имеют некоторые зависимости друг от друга.
С течением времени баги фискятся в любом из этих проектов. Теперь принимается решение выпустить "Bugfix" который содержит только измененные assemblies. Вопрос в том как найти эти измененые assemblies? Бинарное сравнение показвает что изменились все файлы. Разбирать вручную тоже не решение, так как билды и дифы должны строиться на билд-сервере. И build должен построить любой человек из команды а не только тот кто отслеживает все изменения.

Здравствуйте, HotDog, Вы писали:

HD>Обрисую еще раз ситуацию в целом. Есть solution состоящее из ~25 csprj. Csprj имеют некоторые зависимости друг от друга.
HD>С течением времени баги фискятся в любом из этих проектов. Теперь принимается решение выпустить "Bugfix" который содержит только измененные assemblies. Вопрос в том как найти эти измененые assemblies? Бинарное сравнение показвает что изменились все файлы. Разбирать вручную тоже не решение, так как билды и дифы должны строиться на билд-сервере. И build должен построить любой человек из команды а не только тот кто отслеживает все изменения.
Для того что бы выпустить патч к существующим экзешникам / инсталлятору — в любом случае понадобятся исходные бинарники / инсталлятор. Т.е. храните билды, можно отдельно, можно в специальном репозитории. Если сборки не сильно большие — можно просто выпускать полную новую версию.

Здравствуйте, fddima, Вы писали:

F> Для того что бы выпустить патч к существующим экзешникам / инсталлятору — в любом случае понадобятся исходные бинарники / инсталлятор.

Есть исходные бинарники

F> Т.е. храните билды, можно отдельно, можно в специальном репозитории.

Без проблем... сохраним если надо

F> Если сборки не сильно большие — можно просто выпускать полную новую версию.

К сожалению нельзя. Полная версия около 170 Мб, а реально поменялось пару dll на 200 Kb.

Здравствуйте, HotDog, Вы писали:

F>> Т.е. храните билды, можно отдельно, можно в специальном репозитории.
HD>Без проблем... сохраним если надо
Можно конечно не сохранять, но бывает всё таки полезно. Криво второй раз билд можно и не собрать, а можно наоборот. Можно поставить фикс/апдейт на линкер/компилятор и получать уже другой результат. Поэтому оригинальные бинарники, в особенности которые находятся у клиента лучше всё же иметь как они были.

F>> Если сборки не сильно большие — можно просто выпускать полную новую версию.
HD>К сожалению нельзя. Полная версия около 170 Мб, а реально поменялось пару dll на 200 Kb.
Понятно. Ну коли есть оригинальные бинарники, — дело техники с бинарным диффом.

Здравствуйте, TK, Вы писали:

TK>Почему бы не использовать http://blogs.msdn.com/b/jmstall/archive/2006/11/07/binary-diff.aspx ?

Т.е. ты предлагешь использовать mpatch, чтобы "вычислить" разницу?

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

Здравствуйте, fddima, Вы писали:

F> Понятно. Ну коли есть оригинальные бинарники, — дело техники с бинарным диффом.

елы палы, опять двадацть пять Создай плиз тестовый проект, можно пустое консольное приложение.
Скомпилируй в релиз. Скопируй екзешник в другой директорий. Скопилируй проект еще раз. А теперь сравни через бинарный дифф оба экзешника.
Диф покажет что они разные.
В том то и проблема, что я не могу получить 2 одиннаковых файла из одного и того же исходника.

Здравствуйте, HotDog, Вы писали:

HD>Скомпилируй в релиз. Скопируй екзешник в другой директорий. Скопилируй проект еще раз. А теперь сравни через бинарный дифф оба экзешника.
HD>Диф покажет что они разные.
HD>В том то и проблема, что я не могу получить 2 одиннаковых файла из одного и того же исходника.
То что сборки не одинаковые — это понятно. Там как минимум таймштамп. Просто диффами можно было бы патчить вообще всё подряд. А вот полагаться на то, что я в разное время буду получать одни и те же результаты — я лично бы не стал в любом случае — приколы навроде поломавшихся билдов после установки Windows 7 SP1, хотя исходники — не менялись, таки в жизни бывают.
Значит тебе нужно какое-то другое решение, при том оно скорее всего сведется к полу-ручному определению, что нужно обновлять.
Как идея — можно посмотреть, какие конкретно области меняются от билда к билду одной и той же сборки. Посмотреть можно тем же бинарным диффом.
Можно заморачиваться с сорс-контролом. Скажем на hg я получал последнюю ревизию изменений в определенных каталогах (обычно он 1 на 1 соответствует с директорией проекта), но тогда нужно определять на что ссылается проект и что использует (например неподконтрольные сорс-контролу длл) и т.п.
В общем очень может так быть, что станет проще сделать бинарный дифф всем файлам и спать спокойно. Тут всё индивидуально.

Здравствуйте, TK, Вы писали:

TK>Почему тогда при каждом чекине не обновлять версию сборки и отправлять клиенту только те, что больше заданной?

Весь пакет изменений необходимо выпустить под одним номером версии сборки. А так каждая сборка получит свою версию. Можно конечно "ожидаемую версию" кидать как параметр билд серверу и тот будет вносить ее в assembly.cs, но это тоже как то не кузяво выглядит — опять вмешательство оператора.

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

Здравствуйте, fddima, Вы писали:

F> В общем очень может так быть, что станет проще сделать бинарный дифф всем файлам и спать спокойно. Тут всё индивидуально.

У нас программа обновляет сама себя и переделывать загрузчик на бинарные дифы заказчик не согласен. Так как сам механизм апдейтов обкатан и работает без нареканий. А проблемы возникающие на сервере и при построении "дифа" его не интересуют. Вручную составлять дифф работает, но административный оверхед превышает разумные пределы. Человеческий фактор тоже играет большую роль при таком ручном накате апдейтов. Сегодня все прошло нормально, а на следующей неделе коллега ушел в отпуск и на свет выкатили "дохлый" апдейт, так как забыли одну dll...

Здравствуйте, HotDog, Вы писали:

HD>У нас программа обновляет сама себя и переделывать загрузчик на бинарные дифы заказчик не согласен. Так как сам механизм апдейтов обкатан и работает без нареканий. А проблемы возникающие на сервере и при построении "дифа" его не интересуют. Вручную составлять дифф работает, но административный оверхед превышает разумные пределы. Человеческий фактор тоже играет большую роль при таком ручном накате апдейтов. Сегодня все прошло нормально, а на следующей неделе коллега ушел в отпуск и на свет выкатили "дохлый" апдейт, так как забыли одну dll...
Ну тогда нужно искать или писать самому тулзы которые смогут сравниватель сборки.

Здравствуйте, HotDog, Вы писали:

HD>Весь пакет изменений необходимо выпустить под одним номером версии сборки. А так каждая сборка получит свою версию. Можно конечно "ожидаемую версию" кидать как параметр билд серверу и тот будет вносить ее в assembly.cs, но это тоже как то не кузяво выглядит — опять вмешательство оператора.

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

HD>Можно было бы сделать так, что при чекине в какой-нибудь текстовый файл записывался флажок, что проект изменился. А на билд сервере проверять этот флажок и соответсвенно помечать сборку как "измененную". Но тут возникае проблема другого рода. Если сделанные в проекте изменения откатить, то придется вручную сбрасывать этот "флажок".

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

Здравствуйте, HotDog, Вы писали:

HD>>>VS 2010, компилируем в Release одно и то же assembly два раза.
HD>>>Сравниваем результаты в бинарном формате "fc /b ..." и видим что есть различия в бинарниках.

GIV>>Не надо никакого "по умному". Просто надо хранить артефакты. Выпустили версию N, положили в репозиторий. Выпустили версию N + 1, положили в репозиторий и делайте diff сколько хотите раз.

HD>Что значит "положили в репозитарий"? Положили исходники или положили откомпилированные бинарники?
HD>Исходники и так в репозитории. Бинарники бесполезно зачекивать ибо каждая "N+1" версия оличается от N, хотя копилируются из одних и тех же исходников.

Результатом сборки проекта является один или несколько артефактов (exe, dll, installer etc). Их тоже полезно (чтобы делать патчи, например) сохранять в каком то репозитории (это может быть просто папки).

HD>Обрисую еще раз ситуацию в целом. Есть solution состоящее из ~25 csprj. Csprj имеют некоторые зависимости друг от друга.
HD>С течением времени баги фискятся в любом из этих проектов. Теперь принимается решение выпустить "Bugfix" который содержит только измененные assemblies. Вопрос в том как найти эти измененые assemblies? Бинарное сравнение показвает что изменились все файлы. Разбирать вручную тоже не решение, так как билды и дифы должны строиться на билд-сервере. И build должен построить любой человек из команды а не только тот кто отслеживает все изменения.

Информация в каких версиях каких компонент какие баги были пофикшены должна находится в:
* Issue Tracking System
* Version Control System

Впрочем лучше патчить так чтоб результат накладывания патча N->N+1 был неотличим (побайтово) от установки версии N+1.

Здравствуйте, HotDog, Вы писали:

HD>У нас приложение обновляет само себя, и нужно будет это все переделывать, на что заказчик не согласен
Чем аргументирует?

Здравствуйте, para, Вы писали:

P>Здравствуйте, HotDog, Вы писали:

P>у соседей-немерлистов именно таким способом который вам нужен, обновляется бутстрап
P>там используется Ildasm

P>заодно и в билд-процесс встроили

Отлично
Гляну насколько это подходик к нашим условиям

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, HotDog, Вы писали:

HD>>У нас приложение обновляет само себя, и нужно будет это все переделывать, на что заказчик не согласен
WH>Чем аргументирует?

Аргументирует это тем, что все работает так как оно сейчас есть.
И переделывать клиентский софт, чтобы решить какие то внутренние, серверные проблемы — плохое решение

Здравствуйте, para, Вы писали:

P>заодно и в билд-процесс встроили

Проверил этот метод. Если в двух словах — не работает. Вернее работает не всегда.
Компилятор в процессе оптимизации (состояние чекбокса "Optimize code" в настройках проекта роли не играет) создает статический класс вида

[CompilerGenerated]
internal class <PrivateImplementationDetails>{12212EB7-C14C-4369-8C9C-659AE2FA2A49}
{
.....
}

в который выносит к примеру статичные массивы. Т.е. если у меня в коде есть следующая строка

bl.Factors = new float[] { 0f, 0.4f, 0.56f, 0.68f, 0.77f, 0.82f, 0.89f, 0.92f, 0.95f, 0.98f, 1.0f };

то этот bl.Factors будет инициализирован статической переменной из [CompilerGenerated] кода.
Название этого класса меняется при компайле (GUID меняется), естественно и IL code тоже меняется раз от раза.
Можно было бы конечно и вручную произвести подобную оптимизацию, вынести подобные вещи заранее в нами созданный класс,
но кто знает что будет прооптимизированно после установки сервис пака (апдейт компайлера)
или при использовании каких либо иных конструкций языка.
Т.е. никаких гарантий, что мы не "зевнем" какие то важные изменения.