ASP.net Bundle.config VS BundleConfig.cs

Я создал новый проект веб-форм ASP.NET 4.5.1.

Раньше я использовал связывание и минимизацию в MVC 4.

Почему файл bundle.config находится в корневом каталоге, а файл BundleConfig.cs в App_Start — и оба они содержат список файлов, которые должны быть объединены?

Для чего они нужны и почему они делают одно и то же?

Этот вопрос был задан здесь, но на самом деле на него не ответили (хотя он помечен как таковой): Объединение ресурсов через bundle.config и BundleConfig.cs в ASP.NET 4.5 WebForms


asp.net webforms asp.net-4.5
person niico    schedule 29.12.2013    source источник
comment
В моем типе проекта веб-приложения веб-форм (не веб-сайта) я использую ‹%: System.Web.Optimization.Styles.Render(~/bundles/Content/css) %› для материалов, объявленных в BundleConfig.cs, но для материалов, объявленных в Bundle.config я использую Microsoft.AspNet.Web.Optimization.WebForms tagPrefix=webopt следующим образом: ‹webopt:BundleReference ID=Br3 runat=server Path=~/Content/css /› . Первое похоже на MVC, а второе на веб-формы. Я не проверял полностью все возможности в отношении минификации. Использование двух разных сборок оптимизации не является СУХИМ.   -  person subsci    schedule 25.03.2014
comment
Спасибо. Я согласен, что это не СУХОЙ - я хотел бы понять, что лучше, и использовать только один.   -  person niico    schedule 25.03.2014
comment
BundleReference фактически вызывает Styles.Render при обычном рендеринге. Тем не менее, он также поддерживает режим дизайна, так что стили будут применяться там правильно, тогда как с Styles.Render их не будет. Поскольку для проектов MVC нет режима разработки, он там неприменим. Если вам не нужен режим разработки в проектах WebForms, вы можете переключиться на Styles.Render, если хотите.   -  person Elezar    schedule 14.06.2014
comment
возможный дубликат Bundling ресурсы через bundle.config и BundleConfig.cs в веб-формах ASP.NET 4.5   -  person Spontifixus    schedule 08.10.2014

Ответы (1)


arrow_upward
5
arrow_downward

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

Для bundle.config действительно есть только одно преимущество, но оно большое. Используя его, вы можете управлять пакетами, вообще не касаясь кода. Это означает, что вы можете вносить изменения без перекомпиляции, что упрощает быстрое развертывание. Кроме того, это означает, что ваш разработчик внешнего интерфейса, который лучше всего знаком с файлами, которые должны быть объединены, может определить пакеты без необходимости работать с каким-либо внутренним кодом.

Однако есть довольно много ограничений на то, что вы можете указать в Bundle.config. Например, вы не можете указать какие-либо пользовательские преобразования для применения к отдельным элементам или пакетам. Единственные свойства пакета, которые вы можете установить, это Path, CdnPath и CdnFallbackExpression. Вы не можете установить свойства Orderer или EnableFileExtensionReplacements. У вас нет способа включить каталог, включая все подкаталоги (как вы можете с помощью метода IncludeDirectory). По сути, существует МНОЖЕСТВО функций, которые доступны только через внутренний код. Конечно, многое из этого можно было бы настроить, используя внутренний код для извлечения пакета, который был определен в файле bundle.config, а затем манипулируя им. Но если вы собираетесь это сделать, вы также можете создать пакет в бэкэнде.

Моя личная философия заключается в использовании Bundle.config, если мне не нужно делать что-то с пакетом, что невозможно таким образом. Однако я уверен, что некоторые вполне разумные люди не согласятся с этим.

Что касается шаблона VS по умолчанию для проектов Web Forms, имеющего оба варианта, я предполагаю, что он просто демонстрирует доступность обоих вариантов, поскольку он не делает ничего в BundleConfig.cs, чего нельзя было бы сделать в Bundle.config.

person Elezar    schedule 13.06.2014