MSBuild повторно связывает каждый собственный проект после внутренних изменений в dll собственной зависимости

Question

Давайте представим себе такую ​​ситуацию: Project Foo компилируется в Foo.dll и Foo.lib.Project Bar компилируется в Bar.dll и ссылается на Foo как зависимость в проекте VS.

Теперь проблема : почти каждый раз, когда я изменяю внутренние детали (не API, не набор экспортируемых функций)файла Foo.dll - Foo.lib обновляется, а Bar.dll связывается с новым Foo.lib.Если я включаю подробный вывод в VS, я вижу:

Source compilation required: input C:\PROJECTS\FOO\RELEASEUNICODE\FOO.LIB is newer than output C:\PROJECTS\BAR\RELEASEUNICODE\BAR.DLL.

И следующая команда запускает link.exe для связи с новым Bar.dll

Вопрос: Почемуэто случилось?Я не очень знаком с идеей lib-файла для dll (я не видел .a-файл для .so динамической lib в linux), но разве основная идея dll-файла заключается в том, чтобы избежать каких-либо ссылок во время компиляции?Почему файл lib меняется каждый раз, когда я меняю внутренние компоненты файла foo.dll?Есть ли способ избежать повторного связывания зависимой библиотеки?В моем проекте у меня есть десятки библиотек в зависимости от foo.dll, и каждый раз, когда я меняю 10 строк кода в foo.dll - все эти зависимости снова связываются, и это занимает много времени.

Answer 1

MSBuild просто ищет метки времени, когда файл был изменен. Недостаточно умно знать, что публичный API не изменился Таким образом, правило, по которому работает msbuild: если вход более новый, зависимый (в вашем случае столбец) должен быть перестроен (в вашем случае просто перекомпонован).

Я предположил, что если бы msbuild знал об изменениях API, ему пришлось бы анализировать весь код и хранить какую-то базу данных всего кода, что для сборки в большинстве случаев не нужно и очень дорого.