Если это не было сделано, то для этого есть только одна причина: усилия сделать это выше, чем возможные выгоды.
Microsoft определенно не сделает этого, потому что затраты слишком высоки: код .net живет в сборках, и никто не изменит его. И да, сборки предотвращают поэтапную компиляцию. Никто не перестанет использовать сборки.
И вот мой ответ, почему это никому не нужно. Вы можете распределить ваши классы, составляющие один проект, по нескольким сборкам и скомпилировать их одну за другой. Это на самом деле инкрементная компиляция, но не такая детальная, как поэтапная компиляция. И когда ваша архитектура правильно спроектирована, достаточно инкрементной компиляции на уровне сборки.
Редактировать : Хорошо, я скачал компилятор Mono C #, чтобы посмотреть, можно ли сделать его инкрементным. Я думаю, что это не очень сложно. В основном он выполняет следующие шаги: 1) Разбор файлов 2) Компиляция 3) Создание сборки. Вы можете подключиться где-нибудь после того, как типы скомпилированы, и затем сохранить их в промежуточных файлах. Затем перекомпилируйте только измененные. Так что это возможно, но, похоже, это не является первоочередной задачей для команды Mono.
Редактировать 2 : я нашел эту интересную тему , где люди обсуждают инкрементную компиляцию для компилятора Mono C #. Это довольно старое, но ключевое объяснение все еще может быть действительным:
Лексирование и разбор обычно очень
быстро и зависит только от размера
код анализируется. семантический
анализ обычно больше всего времени
шаг потребления, на который ссылается загрузка
Ассамблеи и просеивать вокруг огромного
метаданные для разрешения символов и типов
на самом деле мясо компилятора,
также новый "скомпилированный" код
«добавлен» к этим метаданным / AST что
увеличивает сложность разрешения
символы со временем. Эмиссия кода
сделано в памяти сначала так быстро.
Запись на диск медленная, но зависит от
размер испускаемого кода.
Для пошаговой компиляции, кэширование
метаданные, сделает все очень
быстро, как обычно, очень мало будет
изменен с одного сборника на
Другой. Но gmcs придется
сделать недействительной только часть
метаданные / AST, что не было построено
для .
Редактировать 3 : компилятор C # имел опцию /incremental в v1.0 и v1.1, но он был удален :
Флаг / incremental, найденный в версии 1.0 и 1.1 компилятора C #, теперь считается устаревшим.
Редактировать 4 : Мигель де Икаса дает четкий ответ ( 1 , 2 ), почему Mono Compiler не будет инкрементным:
Есть много, много других мест, где
GMCS был просто не предназначен для работы на
сценарий редактирования и продолжения.
Если кто-то хочет сделать это своим
тема диссертации, это хорошо со мной,
но количество изменений слишком
большой в слишком многих областях. я не буду
даже не хочу перечислять их.
Причина, по которой я не перечислял вещи
потому что они будут повсюду в
компилятор. Я уверен, что вы столкнетесь с
их, как только вы попробуете их; -)
Таким образом, он считает, что это гораздо сложнее, чем для диссертации одного человека. А у Mono гораздо больше актуальных и актуальных задач.