#.net #deployment
#.net #развертывание
Вопрос:
Мы пытаемся выяснить, как определить, отличается ли библиотека dll на пользовательском компьютере от сервера развертывания. Мы не можем использовать временную метку, потому что наш скрипт сборки каждый раз все создает (и именно так мы хотим это сохранить). Мы также предпочитаем не использовать version #, потому что мы определенно можем видеть, что люди часто забывают об этом. Некоторые из наших библиотек dll меняются постоянно (по крайней мере, пару раз в неделю). Я попытался создать XML-файл с хэшем MD5 каждого файла, но, по-видимому, это не сработает, потому что хэш меняется каждый раз, когда мы его компилируем, даже если изменений не было. Есть ли другой способ?
Комментарии:
1. Почему бы не внедрить автоматическое управление версиями, выполняемое вашим сервером сборки, чтобы исключить риск того, что люди забудут установить версии?
2. Анна разве это не означало бы, что каждый файл будет иметь новую версию каждый раз, когда вы выполняете сборку, поскольку в нашей установке все построено? Это, конечно, не сработало бы, если бы это было правдой.
3. Точка @user127954. Вы также могли бы усовершенствовать свою среду сборки, чтобы создавать только то, что вам нужно, и использовать известные версии для зависимостей?
Ответ №1:
Недавно меня попросили выполнить аналогичную задачу, и я использовал надстройку Reflector Diff.
Ответ №2:
Поскольку библиотеки DLL создают разные хэши, ясно, что что-то меняется при каждой компиляции. Возможно, что-то внутреннее зависит от временных меток или рандомизировано.
Теоретически это, вероятно, возможно с помощью reflection или ildasm и некоторого интеллектуального сравнения результатов, но это было бы намного сложнее, чем пересматривать ваш процесс для использования строк с увеличивающейся версией.
Я предлагаю вам автоматизировать процесс сборки и автоматически увеличивать строку версии в assemblyinfo.cs при каждой сборке. Если вы используете систему управления версиями, ваш сценарий сборки может проверить это, увеличить его и вернуть обратно.
Надеюсь, это поможет.
Комментарии:
1. Наверное, я просто надеялся, что есть какая-нибудь утилита, которая могла бы это сделать, но, возможно, нет. Я думаю, нам просто нужно будет потребовать от разработчиков обновить номер версии и согласиться с этим. Автоматизированная часть сборки на самом деле не является решением, если она не была действительно умной и точно знала, что изменилось и что ей нужно скомпилировать. Единственный известный мне способ сделать это — создать другой сценарий сборки для каждой библиотеки dll / exec, тогда порядок сборки, в котором вам нужны материалы, будет изменен, потому что они будут помещены в очередь случайным образом
Ответ №3:
Вероятно, у вас есть инкрементный номер сборки, который включается в какую-либо строку версии вашей библиотеки dll. Вы пробовали выполнять diff для своих библиотек dll? Если это так, вы можете «замаскировать» строку версии на лету для вычисления вашего md5-хэша.