У меня есть проект веб-приложения, ссылающийся на другие проекты и DLL.Некоторое время назад мы добавили флаг optimizeCompilations = "true" в файл web.config, чтобы уменьшить время ожидания первоначального обновления страницы после внесения изменений в один из связанных файлов.Время ожидания сократилось до 15-20 секунд.
Однако в какой-то момент ожидание стало намного длиннее, и я не могу понять, в чем причина.Я прочитал кучу статей об этом флаге и знаю, что одна действительно описывает, как он определяет, когда перекомпилировать весь сайт внутри временной папки Framework.Кажется, что независимо от того, что я перекомпилирую, будь то ссылочная dll или сама dll веб-приложения, когда я захожу на первую страницу, все содержимое временной папки фреймворка воссоздается за 90 секунд.
в любом случае, чтобы отследить, что это вызывает.
Что меня заставляет, так это то, что флаг optimizeCompilation не работает, так это то, что когда он работал, иногда мы сталкивались с одним из тех побочных случаев, когда изменение требовалосайт будет обновлен, и мы получим ошибку.В этот момент мы должны были сделать восстановление, чтобы исправить это.Я не могу вспомнить, когда в последний раз это происходило.
Как я понимаю, даже если Dlls меняются в корне, весь сайт НЕ перекомпилируется, если установлен этот флаг.
Кроме того, я нашел что-то странное.Во временной папке фреймворка для веб-сайта есть файл hash.web, содержащий хэш-код.Я предполагаю, что это код, который компилятор использует, чтобы увидеть, изменилось ли что-то.В качестве теста я записал этот код, внес изменения в исходный файл и скомпилировал.Затем я проверил папку bin и заметил, что единственными измененными файлами были несколько DLL.Я обновил свою веб-страницу в своем браузере, и обновление заняло более минуты.Затем я проверил временную папку фреймворка, и почти все файлы имели текущие данные, то есть все они были перекомпилированы.Однако, когда я проверил хеш-код в hash.web, он был таким же.Я бы подумал, что было бы иначе.