Если самое простое решение в отношении исправлений заключается в том, чтобы сохранить структуру .cs как можно более похожей, то я бы согласился с рекомендацией Андреаса переместить App_Code как минимум в 1 другой проект.
Скотт Гатри опубликовал несколько советов по ускорению компиляции в VS 2005, вы не указали, в какой версии вы работали, но применяются те же советы по скорости. Второй раздел его поста посвящен проектам веб-сайтов.
Еще один совет: если вы работаете со страницами, а не кодируете на самом деле в каталоге App_Code, есть опция сборки, которая может быть полезна . Перейдите на страницу Свойства проекта > Сборка > Изменить Перед запуском стартовой страницы с веб-сайта сборки на Страница сборки , это создаст только запуск страница, когда вы запускаете отладчик. Я не уверен, что этот сценарий случается часто, но если большая часть вашей работы происходит на страницах, а не в App_Code, это сэкономит вам много времени на компиляцию.
App_Code должен быть собран вместе, вам следует избегать размещения ваших кодов и т. Д. Все, что может быть в другом месте, должно быть. Замечание: время компиляции, по крайней мере при отладке, обычно в 30-50 раз быстрее в веб-приложении. При этом вы должны перекомпилировать все приложение при каждом изменении кода, чтобы были недостатки ... но с изменениями в пространстве имен и т. Д. Я понимаю, что вам понадобятся исправления.
Кроме того, имейте в виду, что когда вы разделяете код на другие проекты, помимо упрощения универсального подхода с точки зрения компиляции, Visual Studio не нужно будет компилировать эти другие проекты зависимостей, если они не изменились. В настоящий момент все является честной игрой, потому что все, что может измениться в вашем проекте, может повлиять на что-то еще там ... однако, если вы разделите его, Visual Studio будет компилировать ваши другие проекты только тогда, когда они изменятся или проект они ссылаются, перестраивается.