VS2010 генерирует разные сборки каждый раз при компиляции проекта

У меня есть несколько проектов C #. Я добавил событие post build к тем проектам, которые копируют полученную сборку (dll) из корзины в общую папку.

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

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

Я где-то читал, что dll хранит отметку времени компиляции, и если это правда, я не могу это исправить. Если да, то как вы управляете своей общей DLL таким образом, чтобы ваш репозиторий (Git / HG) не фиксировал все ваши скомпилированные проекты, которые не были изменены?

Спасибо, Эран.


visual-studio-2010 c# silverlight
person Eran Sakal    schedule 05.12.2012    source источник
comment
Это хорошо известное поведение: blogs.msdn.com/b/ericlippert/archive/2012/05/31/: компилятор C # по своей конструкции никогда не создает один и тот же двоичный файл дважды. Компилятор C # встраивает только что сгенерированный GUID в каждую сборку каждый раз, когда вы ее запускаете, тем самым гарантируя, что никакие две сборки никогда не будут побитно идентичными.   -  person Daniel Hilgarth    schedule 05.12.2012
comment
См. stackoverflow.com/questions/1335427/, чтобы узнать, почему они разные   -  person stuartd    schedule 05.12.2012
comment
@DanielHilgarth спасибо за быстрый ответ. Так люди справляются с этим с точки зрения контроля версий? Это приводит к тому, что репозиторий очень быстро становится огромным ...   -  person Eran Sakal    schedule 05.12.2012
comment
FWIW, наш магазин сообщает системе управления версиями игнорировать определенные файлы и папки - мы не видим необходимости помещать скомпилированные сборки в систему управления версиями.   -  person Mike Hildner    schedule 05.12.2012
comment
@EranSakal: Пожалуйста, посмотрите мой ответ.   -  person Daniel Hilgarth    schedule 05.12.2012

Ответы (2)


arrow_upward
0
arrow_downward

Чтобы ответить на конкретный вопрос «Как вы управляете своей совместно используемой DLL таким образом, чтобы ваш репозиторий (Git / HG) не фиксировал все ваши скомпилированные проекты, которые не были изменены?», У меня есть очень простой ответ: < сильный> игнорировать.

Мы исключаем /bin и /obj из каталогов, которые система управления версиями попытается зафиксировать. Это означает, что вам нужно будет перекомпилировать код на каждой машине после каждого изменения, но Visual Studio все равно сделает это для любого проекта, в котором код был изменен.

person Bobson    schedule 05.12.2012
comment
Но мое приложение разделено на несколько решений (решение на уровне). Чтобы разделить сборки между этими слоями, я должен выполнить ссылку на файл в общую / общую папку, в которой хранятся все соответствующие сборки. - person Eran Sakal; 05.12.2012
comment
@EranSakal - Что произойдет, если кто-то внесет изменение в одно решение, которое нарушит совместимость dll с уровнем выше? Смогут ли они вообще узнать, что внесли решающее изменение? - person Bobson; 06.12.2012

arrow_upward
0
arrow_downward

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

введите описание изображения здесь

person Daniel Hilgarth    schedule 05.12.2012
comment
Я думал установить это свойство, но оно все равно будет происходить в следующих сценариях: 1. Восстановление моего решения. 2. клонирование репозитория из центрального расположения. - person Eran Sakal; 05.12.2012
comment
@EranSakal: Вы должны подумать, почему вы действительно хотите поместить эти сборки в свою VCS. Для этого нет никаких причин. - person Daniel Hilgarth; 05.12.2012
comment
мое приложение разделено на несколько решений (решение для каждого слоя). Чтобы разделить сборки между этими слоями, я должен выполнить ссылку на файл в общую / общую папку, в которой хранятся все соответствующие сборки. - person Eran Sakal; 05.12.2012