Я могу запустить приложение Asp.Net MVC 2 без проблем на моем локальном компьютере. Просто запустите / отладите.
Но если я его уже построил, то не могу опубликовать! Придется очистить решение и опубликовать его снова. Я знаю, что это не критично для системы, но это действительно раздражает. «Публикация в один клик» не означает «Чистое решение, а затем публикация в один клик»
Точная ошибка выглядит следующим образом:
Ошибка 11 Использование раздела, зарегистрированного как allowDefinition = 'MachineToApplication' за пределами уровня приложения, является ошибкой. Эта ошибка может быть вызвана тем, что виртуальный каталог не настроен как приложение в IIS.
Я подозреваю, что это как-то связано с Web.Config в папке Views, но тогда почему только после того, как я один раз собрал. Следует отметить, что после публикации приложение работает нормально.
Ответы:
у меня была такая же проблема с моими приложениями MVC. это было неприятно, потому что я все еще хотел, чтобы мои представления проверялись, поэтому я не хотел отключать MvcBuildViews
К счастью, я наткнулся на сообщение, которое дало мне ответ. оставьте MvcBuildViews равным true , тогда вы можете добавить следующую строку внизу в свой файл проекта:
И сделайте эту папку не в папке вашего проекта. Работает для меня. Это не идеальное решение, но пока оно хорошее. Убедитесь, что вы удалили папку пакета (расположенную внутри папки obj \ Debug и / или obj \ Release ) из папки проекта, иначе вы будете продолжать получать ошибку.
FWIW, MS знает об этой ошибке ...
источник
\obj
путь), а НЕ MvcBuildViews. Разница небольшая, но существенная.Я удалил все из моей папки obj / Debug и исправил эту ошибку. Это позволило мне уйти в
вариант в моем файле проекта (который пригодится с шаблоном T4MVC T4).
Изменить: этого можно достичь намного проще, просто используя меню «Сборка» -> «Перестроить решение» (потому что на самом деле перестройка очищает папку obj / Debug и затем создает решение).
источник
Я использую этот обходной путь на странице MS Connect для этой ошибки. Он очищает все файлы obj и temp в вашем проекте (все конфигурации) перед запуском AspNetCompiler.
источник
rmdir /S /Q "$(ProjectDir)\obj"
в раздел пост-сборки согласно Microsoft Ticket решило проблему!Эта проблема возникает, когда в папке obj есть выходные данные веб-проекта (шаблонный файл web.config или временные файлы публикации). Используемый компилятор ASP.NET недостаточно умен, чтобы игнорировать содержимое папки obj, поэтому вместо этого он выдает ошибки.
Другое исправление - уничтожить вывод публикации прямо перед вызовом <AspNetCompiler>. Откройте свой .csproj и измените это:
к этому:
Это удалит все web.configs в \ obj, а также все папки PackageTmp в \ obj.
источник
obj
папке был мусор.<ItemGroup>
недействительны, но игнорируйте это - он все равно работает.Если вы используете веб-публикацию, вы можете установить
MvcBuildViews=false
иPrecompileBeforePublish=true
, которые предварительно компилируются после копирования во временную папку (непосредственно перед публикацией / пакетом).ПРИМЕЧАНИЕ.
PrecompileBeforePublish
Поддерживается только «новым» стеком конвейера веб-публикации (VS2010 SP1 + Azure SDK или VS2012 RTM). Если вы используете VS2010 RTM, вам понадобится один из альтернативных методов.источник
Что касается решения от jrummell, настройка:
DependsOnTargets="CleanWebsitesPackage;CleanWebsitesPackageTempDir;CleanWebsitesTransformParametersFiles;"
Он работает в VS 2010 , но не в VS 2012 . В 2012 году необходимо поставить:
DependsOnTargets="CleanWebsitesPackage;CleanWebsitesWPPAllFilesInSingleFolder;CleanWebPublishPipelineIntermediateOutput"
Источник:
VS 2010: C: \ Program Files (x86) \ MSBuild \ Microsoft \ VisualStudio \ v10.0 \ Web \ Microsoft.Web.Publishing.targets
VS 2012: C: \ Program Files (x86) \ MSBuild \ Microsoft \ VisualStudio \ v11.0 \ Web \ Microsoft.Web.Publishing.targets
источник
Я знаю, что на это был дан ответ, но я просто хотел добавить кое-что интересное, что нашел.
Я установил для «MvcBuildViews» значение false в проекте, удалил все папки bin и obj, и я все еще получал ошибку. Я обнаружил, что существует файл «.csproj.user», в котором для «MvcBuildViews» все еще установлено значение «истина».
Я удалил файл ".csproj.user", и все заработало.
Поэтому убедитесь, что при изменении файла csproj вы также изменяете или удаляете файл ".csproj.user".
источник
У меня тоже была эта проблема, поэтому я создал событие предварительной сборки в свойствах проекта, чтобы очистить выходные каталоги (
${projectPath}\bin,${projectPath}\obj\${ConfigurationName}
). В другом проекте я также получал эту ошибку, даже при наличии события очистки. Во втором проекте я компилировал представления, перечисленные в файле проекта:Я изменил true на false, и он больше не жаловался на эту ошибку, но все равно работал правильно. Я не буду утверждать, что точно знаю, что вызвало вторую ошибку, но, по крайней мере, на данный момент это заставило меня двигаться вперед.
источник
Проблема связана с промежуточными файлами, но есть другое решение, которое состоит в очистке этих промежуточных файлов перед построением представлений.
Это решение было включено в некоторую версию VS, но я могу только сказать, что у меня была проблема в VS 2013 Update 5. (см. «Осторожно» ниже, это может быть исправлено в этой версии, но не работает только в моем конкретном нестандартный корпус).
Я позаимствовал решение из Error: allowDefinition = 'MachineToApplication' за пределами уровня приложения в Visual Studio Connect.
Решение состоит во включении этих строк в проект (
.csproj
файл) веб-приложения, которые обрабатывают удаление промежуточных файлов offedning:Осторожно: по какой-то причине, вероятно, потому, что я сам включил его в проект, моя цель сборки для построения представлений была названа
"BuildViews"
вместо"MvcBuildViews"
, поэтому мне пришлось соответствующим образом изменитьBeforeTargets
атрибут. Я также упростил цель, удаливPropertyGroup
и упростив условие, например:источник
В моем случае я видел, что когда у меня есть MvcBuildViews и PrecompileDuringPublish как истинные, это было причиной этой проблемы.
Поэтому я удалил PrecompileDuringPublish, и это решение сработало для меня, и с тех пор я не сталкивался с этой проблемой.
источник