Я решил свою проблему. Оказывается, проблема не имеет ничего общего с IIS и его конфигурацией или чем-то подобным, но вместо этого является побочным продуктом того, как VS2010 публикует веб-приложения.
Так что, как и большинство из нас, мы на самом деле не отлаживаем приложения под Cassini - вместо этого мы используем IIS, указывающий на наш исходный код, который мы постоянно меняем. Что ж, с настройками по умолчанию для функции публикации, VS2010 выполняет компиляцию приложения (и зависимостей) и копирует соответствующие файлы в папку в специальном подкаталоге obj внутри корневого расположения вашего проекта. Внутри этой «копии» веб-приложения, которое оно будет пытаться развернуть, включен файл web.config, который будет развернут. Этот конфигурационный файл содержит вещи, которые должны быть в файле web.config в корне приложения. Но имейте в виду, что наш исходный код находится внутри приложения IIS. Поэтому, как только этот файл сгенерирован (после того, как мы скомпилировали / собрали релиз), мы теперь нарушаем требования IIS на нашей машине dev / build.
Так что все в порядке, если VS успешно публикует приложение и удаляет эту временную копию. Единственная проблема заключается в том, что VS НЕ удаляет эту временную копию (в ~/obj/Release/Package/PackageTmp), независимо от того, успешна она или нет. Поэтому, как только вы попытаетесь опубликовать один раз, вы не сможете успешно скомпилировать свое приложение без этой ошибки, намекающей на проблему в конфигурации IIS, и эта ошибка предотвратит будущую публикацию.
Итак, мой обходной путь - просто удалить папку obj после публикации. Другие функциональные обходные пути могут включать установку этого параметра в папку вне пути к каталогу отладки приложения IIS (имеет преимущества с системами контроля версий) или добавление приложения IIS для отладочных / выпускных копий в папке obj (имеет другие потенциальные преимущества). В общем, это была очень запутанная проблема с некоторыми довольно простыми обходными путями.