2013-02-14 5 views
7

У нас есть проект и он хотел бы построить представления для генерации ошибок времени компиляции, если в файлах .cshtml Views есть что-то неправильное.ASP.Net MVC MvcBuildViews значительно увеличивает время компиляции

Тем не менее, компилировать время увеличивается резко:

  • MvcBuildViews = true занимает 62 секунд
  • MvcBuildViews = false занимает 9 секунд

Является ли это что-то приемлемо? Потому что увеличение довольно резкое, в котором нам не терпится ждать таких компиляций. Как можно улучшить такую ​​компиляцию?

Проект до сих пор насчитывает около 130 видов & Частичные виды (.cshtml-файлы). Является ли это большим/средним/небольшим?

+0

http://www.luisrocha.net/2011/10/avoiding-mvcbuildviews-build-time.html –

+0

Попробуйте альтернативу StackOverflow: [StackExchange.Precompilation] (https://stackoverflow.com/a/35977582/1141876) – fiat

ответ

2

Мы боролись с той же проблемой. Мы начали компилировать Views, чтобы поймать очевидные проблемы, которые будут ползать на нас во время Интеграционные тесты и UX Tests. Еще хуже были ошибки, которые каким-то образом вошли в производство.

Но, как вы заметили, наши времена постройки стали невыносимыми. Как и вы, наши разработчики строят бесчисленное количество раз, и это стало важной частью нашего дня. У нас были анекдоты о тестировании после обеда, поэтому сборка могла быть выполнена, когда мы были вне дома.

Мы в конечном итоге переехали в здание до UX-тесты.

Теперь мы движемся к предварительной компиляции. На данный момент только один парень из нашей команды принял его, и, по-видимому, предварительные компиляции заметно лучше, чем сборки (пошаговые и итоговые). И настройка - это, в основном, nuget fetch.

Эти статьи должны быть хорошим началом

http://stacktoheap.com/blog/2013/01/19/precompiling-razor-views-in-asp-dot-net-mvc-3/

http://blog.davidebbo.com/2011/06/precompile-your-mvc-views-using.html

+0

Спасибо, проверим! :) –

11

Ну, я думаю, имея возможность компилировать мнения является хорошая вещь сама по себе, но я не могу долго ждать, либо. Так что я предпочитаю сделать, это добавить, что MvcBuildViews = true внутри ProperyGroup Выпуска, так что вы только обобщить мнения во время выпуска и до развертывания

Групповое свойство должно выглядеть следующим образом:

<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' "> 

Поэтому поставьте

<MvcBuildViews>true</MvcBuildViews> 

Внутри этого блока. таким образом вы все еще компилируете свои представления один раз, а не каждый раз, когда вы пытаетесь отлаживать ...

+0

Мы тоже использовали этот подход. Legit. –

0

Установите MvcBuildView на false в csproj для конфигурации отладки.

<MvcBuildViews Condition=" '$(Configuration)' != 'Debug' ">true</MvcBuildViews> 

Добавьте следующую внешнюю команду в меню «Инструменты/Внешние инструменты»

Title: Compile with MVC views 
Command: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe 
Arguments: $(SolutionDir)$(SolutionFileName) /p:MvcBuildViews=true 
Initial directory: $(SolutionDir) 
Use Output window: checked 

Затем добавить ярлык к этому: Перейдите в меню Сервис/Параметры/Environnement/клавиатура Найдите команду «Инструменты .ExternalCommandX ", где X - это позиция вашей внешней команды, в которую вы только что добавили ее. Назначьте ключ (пример: Ctrl-shift-1)

Теперь объяснения: У нас та же проблема. Мы не хотим компилировать представления большую часть времени, но нам нравится компилировать их перед проверкой кода, таким образом мы собираем представления 1 раз из 50 или что-то в этом роде. Чтобы добиться этого, я добавил внешнюю команду инструмента для msbuild с параметром mvcbuildviews. Единственный недостаток заключается в том, что ошибки не указаны в окне ошибок визуальной студии, вам нужно посмотреть окно вывода и дважды щелкнуть по ошибкам, если таковые имеются.

Смежные вопросы