Связывание ресурсов через bundle.config vs BundleConfig.cs in ASP.NET 4.5 Вебформы

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

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

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

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

моя личная философия заключается в использовании пакет.config, если мне не нужно делать что-то с пакетом, что невозможно таким образом. Однако, я согласен, что иметь их все в одном месте идеально. Если я решу, что мне нужно использовать класс, то я буду использовать это для все моих Пучков этого типа (я иногда кладу свои пучки JS в класс и мои пакеты CSS в.конфигурационный файл, однако). Я уверен, что некоторые вполне разумные люди не согласились бы с этим процессом.

может ли кто-нибудь объяснить разницу в использовании ресурсов связывания использование BundleConfig.файл класса cs в отличие от пакета.конфиг xml-файл?

разница в том, что вам придется читать, анализировать и загружать содержимое пакета.конфигурации во время выполнения. Следовательно, используя BundleConfig.файл класса cs может быть проще.

1) Почему бы вам просто не сделать их обоих одним конкретным способом для простоты

полностью соглашаться.

2) почему кто-то предпочел бы такие ресурсы жесткого кода в файле класса?

проще говоря: легко понять.

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

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

также, если есть какая-либо реальная документация по системе.Сеть.Оптимизация, Я хотелось бы знать местоположение (потому что я уверен, что не могу его найти).

уже ответил выше, но я бы повторил:http://www.asp.net/mvc/tutorials/mvc-4/bundling-and-minification