Здравствуйте, Слава, Вы писали:
С>У меня есть код где-то на сервере, я хочу знать, какой именно.
А что значит "код на сервере"? Папка c гит-репозиторием? Собранные бинарники?
С>4 Либо предположить, что один и тот же код даст одну и ту же сборку, с одним и тем же хэшем, а хэш от хэшей всех загруженных моих сборок на сервере даст тот же самый результат, что и у меня локально С>Воспроизводимы ли сборки в .NET 8? Возможно ли реализовать пункт 4?
By default, compiler output from a given set of inputs is unique, since the compiler adds a timestamp and an MVID (a Module.ModuleVersionId. Basically it is a GUID that uniquely identifies the module and version.) that is generated from random numbers. You use the <Deterministic> option to produce a deterministic assembly, one whose binary content is identical across compilations as long as the input remains the same. In such a build, the timestamp and MVID fields will be replaced with values derived from a hash of all the compilation inputs.
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, _FRED_, Вы писали:
_FR>Здравствуйте, Слава, Вы писали:
С>>У меня есть код где-то на сервере, я хочу знать, какой именно.
_FR>А что значит "код на сервере"? Папка c гит-репозиторием? Собранные бинарники?
С>>4 Либо предположить, что один и тот же код даст одну и ту же сборку, с одним и тем же хэшем, а хэш от хэшей всех загруженных моих сборок на сервере даст тот же самый результат, что и у меня локально С>>Воспроизводимы ли сборки в .NET 8? Возможно ли реализовать пункт 4?
_FR>Просмотрите на опцию компиляции Deterministic:
У меня есть код где-то на сервере, я хочу знать, какой именно.
Для этого я могу:
1 Либо руками вводить названия версий в сборку (высунув язык от усердия)
2 Либо задействовать какое-то автоверсионирование, которое будет увеличивать число при — при каком событии? При каждом изменении и нажатии ctrl+s в Студии?
3 Либо добавить в .csproj настройку, которая будет брать хэш последнего коммита Git и имя ветки, и засовывать это в атрибут сборки. Переименовал одну переменную — коммить. Очень неудобно.
4 Либо предположить, что один и тот же код даст одну и ту же сборку, с одним и тем же хэшем, а хэш от хэшей всех загруженных моих сборок на сервере даст тот же самый результат, что и у меня локально
Воспроизводимы ли сборки в .NET 8? Возможно ли реализовать пункт 4?
С>1 Либо руками вводить названия версий в сборку (высунув язык от усердия)
номер сборки на build-сервере прописать в build или revision (major.minor.build.revision)
С>2 Либо задействовать какое-то автоверсионирование, которое будет увеличивать число при — при каком событии? При каждом изменении и нажатии ctrl+s в Студии?
Номер хранится в файле в source control и увеличивается автоматически при каждой сборке build`а на build-сервере.
Через include попадает в assemblyinfo всех проектов.
С>4 Либо предположить, что один и тот же код даст одну и ту же сборку, с одним и тем же хэшем, а хэш от хэшей всех загруженных моих сборок на сервере даст тот же самый результат, что и у меня локально С>Воспроизводимы ли сборки в .NET 8? Возможно ли реализовать пункт 4?
Не знаю насчет .NET 8, но раньше точно были какие-то метаданные, препятствующие воспроизводимым сборкам. С другой стороны, если известно, что это за метаданные, то почему бы не исключать их из хэширования.
А тебе нужен обязательно тот же хэш? Недостаточно сборки из тех же исходников?
Здравствуйте, m2user, Вы писали:
M>Номер хранится в файле в source control и увеличивается автоматически при каждой сборке build`а на build-сервере. M>Через include попадает в assemblyinfo всех проектов.
У меня нет никакого билд-сервера, на билд-сервер код попадает через коммиты, при наличии коммита задачу можно считать уже решённой.
M>Не знаю насчет .NET 8, но раньше точно были какие-то метаданные, препятствующие воспроизводимым сборкам. С другой стороны, если известно, что это за метаданные, то почему бы не исключать их из хэширования. M>А тебе нужен обязательно тот же хэш? Недостаточно сборки из тех же исходников?
На самом деле, мой вопрос стоило бы разместить в разделе форума "Идиотские задачи", но такого нет.
Представьте, что есть непонятный проект, за который то ли платят, то ли нет, и разработчик деплоится по много раз на дню, чтобы посмотреть, что теперь сломается, при этом не особо соблюдая дисциплину. Стало быть, возникает задача выяснить при очередном подходе к проекту — там задеплоен текущий код или чуть другой?
Оно гарантирует бинарно идентичную сборку?
По ссылке я вижу, что предлагается брать из pdb информацию по параметрам компиляции и исходникам. Что даст функционально идентичную сборку.
MS в статье про отладку и pdb ссылается на заметку 2007 г, где утверждается следующее:
Due to the numerous and varied methods and implementations for optimizing code, it is always possible that one build ended up with a little more time to do something extra or different than another build did.
Thus, the final result could be a different set of bits for what is the same functionality.
<...>
However, compiler/linker determinism is not guaranteed, our debugger cannot depend on it. Furthermore, we would much rather not take the support cost of allowing some sort of override.
Здравствуйте, _FRED_, Вы писали:
С>>У меня есть код где-то на сервере, я хочу знать, какой именно.
_FR>А что значит "код на сервере"? Папка c гит-репозиторием? Собранные бинарники?
