Компиляция представлений в ASP.NET MVC
Я хочу, чтобы задача msbuild скомпилировала представления, чтобы я мог видеть, есть ли ошибки времени компиляции ... во время компиляции. Любые идеи?
Ответы 8
Для этого можно использовать aspnet_compiler:
C:\Windows\Microsoft.NET\Framework\v2.0.50727\aspnet_compiler -v /Virtual/Application/Path/Or/Path/In/IIS/Metabase -p C:\Path\To\Your\WebProject -f -errorstack C:\Where\To\Put\Compiled\Site
где «/ Виртуальный / Приложение / Путь / Или / Путь / В / IIS / Метабаза» - это что-то вроде этого: «/ MyApp» или «/ lm / w3svc2 / 1 / корень /»
Также в MSDN есть Задача AspNetCompiler, показывающий, как интегрировать aspnet_compiler с MSBuild:
<Project xmlns = "http://schemas.microsoft.com/developer/msbuild/2003">
<Target Name = "PrecompileWeb">
<AspNetCompiler
VirtualPath = "/MyWebSite"
PhysicalPath = "c:\inetpub\wwwroot\MyWebSite\"
TargetPath = "c:\precompiledweb\MyWebSite\"
Force = "true"
Debug = "true"
/>
</Target>
</Project>
Это устарело, см. Отрывок из документа readme ниже.
другой ответ описывает задачу проекта более подробно, но часть aspnet_compiler по-прежнему верна (и полезна для агентов сборки).
В следующем выпуске ASP.NET MVC (доступном примерно в январе) должна быть задача MSBuild, которая компилирует представления, так что вы можете подождать.
См. объявление
Кроме того, если вы используете Resharper, вы можете активировать Solution Wide Analysis, и он обнаружит любые ошибки компилятора, которые могут возникнуть в файлах aspx. Вот что мы делаем ...
Это правда, что это работает для файлов aspx, но анализ всего решения не включает файлы ascx (пользовательские элементы управления)
Я считаю, что это работает в R # 5, но это огромная трата ресурсов для больших проектов (даже на моем домашнем компьютере с 16 ГБ его не стоит использовать).
@Andrew / @ mookid8000 - R # также будет обнаруживать ошибки, которые не распознает компилятор, такие как отсутствующие / неправильные представления и действия. R # немного замедлит ваш компьютер (я считаю, что это нормально для большого проекта с 4 ГБ оперативной памяти и гиперпоточным процессором), но я легко возвращаю время, которое трачу на его ожидание, и в конечном итоге выполняю меньше операций на моем код, поскольку R # предоставляет операции более высокого уровня, которые объединяют множество шагов, которые мне пришлось бы предпринять для выполнения той же задачи вручную. Ваш проект должен быть огромным!
Для больших проектов "немного замедлите работу вашего ПК" - это ничего не значит. Моя машина сборки имеет 16 ГБ ОЗУ и 8 ядер (2 Xeon), и она просто КРАСИТСЯ. У меня такое чувство, что R # просто не был создан для проектов нашего размера ... например. у нашего решения ~ 30 проектов, пара миллионов LOC и много сотен просмотров. Мне нравится R # в наших небольших проектах (например, несколько проектов и не более 50 просмотров), но в нашем большом нам всегда приходится отключать его.
Это МОЖЕТ работать, но УБЕГАТЬ! Я включил это, думая, что мое решение было маленьким, и оно так и не закончило «анализировать» и съело всю мою оперативную память и процессор. Мне потребовалось 15 минут, чтобы прийти в себя.
Из документа readme word для RC1 (не проиндексировано Google)
Шаг после сборки компилятора ASP.NET
В настоящее время ошибки в файле просмотра не обнаруживаются до выполнения. Чтобы вы могли обнаруживать эти ошибки во время компиляции, проекты ASP.NET MVC теперь включают свойство MvcBuildViews, которое по умолчанию отключено. Чтобы включить это свойство, откройте файл проекта и установите для свойства MvcBuildViews значение true, как показано в следующем примере:
<Project ToolsVersion = "3.5" DefaultTargets = "Build" xmlns = "http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<MvcBuildViews>true</MvcBuildViews>
</PropertyGroup>
Примечание Включение этой функции увеличивает накладные расходы на время сборки.
Вы можете обновить проекты, созданные с помощью предыдущих выпусков MVC, чтобы включить проверку представлений во время сборки, выполнив следующие шаги:
- Откройте файл проекта в текстовом редакторе.
- Добавьте следующий элемент под самый верхний элемент
<PropertyGroup>:<MvcBuildViews>true</MvcBuildViews> - В конце файла проекта раскомментируйте элемент
<Target Name = "AfterBuild">и измените его, чтобы он соответствовал следующему:
<Target Name = "AfterBuild" Condition = "'$(MvcBuildViews)'=='true'">
<AspNetCompiler VirtualPath = "temp" PhysicalPath = "$(ProjectDir)\..\$(ProjectName)" />
</Target>
Если это не должно работать для вашего проекта, проверьте, нет ли <MvcBuildViews> false </MvcBuildViews> где-нибудь в вашем файле проекта. Он переопределял новый элемент <MvcBuildViews>, который я добавил поверх него.
@mxmissile: Скотт Гатри рекомендовал добавить проект веб-развертывания в ваше решение, чтобы получить такую поддержку в проектах веб-приложений: weblogs.asp.net/scottgu/archive/2006/09/22/…
Убедитесь, что для EnableUpdateable установлено значение false, иначе представления не будут предварительно скомпилированы. <EnableUpdateable> false </EnableUpdateable> <MvcBuildViews> true </MvcBuildViews> (devcarl.posterous.com/…)
У меня проблема с этим, когда пространство имен по умолчанию импортируется в web.config, но страницы не компилируются, есть подсказки?
Почему, почему, почему ... нет сочетания клавиш для построения с видами или без них? МС почему?
Это решение, добавленное к инструментам MVC. stackoverflow.com/a/2670792/878612
Для меня это решение отображает ошибки в сгенерированных файлах .cs, а не фактические ошибки в файлах .cshtml. Есть ли способ изменить это? Это не совсем удобно.
Он работает, но двойной щелчок по ошибке в списке ошибок не открывает представление - все равно, чтобы это сделать?
После применения вышеуказанного решения я начал получать ошибку, относящуюся к моему web.config (из-за того, что в моей папке obj существовала версия выпуска). Чтобы исправить это, вы можете удалить папки obj на этапе BeforeBuild. Источник: gunnarpeipman.com/aspnet/…
12 лет спустя все еще занимаюсь этим ...
Приведенный здесь ответ работает для некоторых версий MVC, но не для других.
Простое решение работало для MVC1, но при обновлении до MVC2 представления больше не компилировались. Это произошло из-за ошибки в файлах проекта веб-сайта. См. Эту статью Haacked.
Смотрите это: http://haacked.com/archive/2011/05/09/compiling-mvc-views-in-a-build-environment.aspx
Честно говоря, я бы порекомендовал пакет nuget RazorGenerator. Таким образом, ваши представления имеют файл .designer.cs, сгенерированный при их сохранении, и помимо получения ошибок времени компиляции для ваших представлений, они также предварительно компилируются в сборку (= более быстрый разогрев), а Resharper также предоставляет некоторую дополнительную помощь.
Чтобы использовать это, включите пакет nuget RazorGenerator в свой проект ASP.NET MVC и установите расширение «Генератор бритвы» в разделе Инструменты → Расширения и обновления.
Мы используем это, и накладные расходы на компиляцию с этим подходом намного меньше. Вдобавок к этому я бы, вероятно, порекомендовал .NET Demon от RedGate, который еще больше значительно снижает влияние времени компиляции.
Надеюсь это поможет.
есть ли подобное решение для VS2012?
К сожалению, он поддерживает только C# и не поддерживает VB.Net
@zoidbergi RazorGenerator работает с VS2012; при использовании RazorGenerator.Mvc и RazorGenerator.MsBuild: расширение не требуется. См. Запись в блоге на stacktoheap.com
Может ли это использоваться только для поиска ошибок - или он заменяет механизм просмотра при развертывании приложения?
Я установил пакет nuget RazorGenerator и расширение Razor Generator. В моем проекте ничего не изменилось. Файлы .designer.cs не появлялись. Использую Visual Studio 2017.
@MichaelSamteladze Не тестировал .NET Core и давно не работал с Razor, но, предполагая, что вы используете полную структуру, взгляните на документы Razor Generator здесь: github.com/RazorGenerator/RazorGenerator Самый простой - использовать Enable-RazorGenerator в консоли диспетчера пакетов . Удачи!
@MichaelSamteladze Я пробовал (предостережение с 1 минутой инвестиций) на ядре безуспешно (на страницах или представлениях), и я не уверен, что посоветовал бы кому-либо использовать ASP.NET MVC (то есть не-.Core) сегодня, если они намеревались для использования страниц или представлений Razor и для того, чтобы приложение работало какое-то время (если это новое поле), если нет веских аргументов против Core. Понятия не имею, что применимо к вашему случаю.
@Mirko, мой проект - это не .NET Core, у меня есть обычное веб-приложение MVC5.
Использование расширения немного помогает Visual Studio Электроинструменты для повышения производительности (бесплатно). В частности, функция Solution Error Visualizer. С его помощью ошибки компиляции помечаются визуально в проводнике решений (в исходном файле, где была обнаружена ошибка). Однако по какой-то причине эта функция не работает, как с другими ошибками, где-либо еще в коде.
В представлениях MVC любые ошибки времени компиляции будут по-прежнему подчеркнуты красным цветом в соответствующих файлах .cs, но сигнал об этих ошибках не распространяется вверх в обозревателе решений (ни в коем случае, даже не в исходном файле).
Спасибо BlueClouds за исправление моего предыдущего утверждения.
Я только что сообщил об этом как проблема в проекте расширения github.
Я попробовал Productivity Power Tools. Но ведет себя не так, как здесь сказано. Ошибка при просмотре бритвы, но сборка выполнена успешно. представления не отмечены и не подчеркнуты красным цветом или где-либо в дереве обозревателя решений.
@BlueClouds: вы правы. Я создал образец проекта и добавил в представление ошибку времени компиляции. Расширение подчеркнет ошибочные строки красным цветом, но не будет распространять ошибку в обозревателе решений. Исправляю то, что я сказал в ответе. Я оставляю ответ здесь, так как он все еще немного помогает, хотя на самом деле не решает проблему эффективно.
Сборка> Выполнить анализ кода
Горячая клавиша: Alt + F11
Помогли мне отловить ошибки Razor.
Я поддержал этот ответ, потому что горячая клавиша действительно выявила ошибку Razor. Однако впоследствии я заметил, что это работает, только если в среде IDE открыт файл .cshtml.
Я не знаю, какой модуль просмотра вы используете, но если вы используете Razor, вы можете проверить мое сообщение в блоге: <a href = "chrisvandesteeg.nl/2010/11/22/… ваш asp.net mvc Razor просматривает в отдельной dll </ a > Должно быть возможно использовать этот код и для других движков просмотра, но это еще не сделано и не протестировано.