Agrupar recursos a través de bundle.config vs BundleConfig.cs en ASP.NET 4.5 Formularios web

Por lo que puedo decir, la respuesta aceptada en realidad no responde a la pregunta en absoluto. Se discuten los beneficios del framework de agrupación, pero no cómo usar BundleConfig.cs es diferente a usar el paquete.archivo de configuración.

Mucho de esto se reduce a si prefiere trabajar en código o en marcado, pero cada uno tiene algunas ventajas que son específicas de ese método.

Para el paquete.config, realmente solo hay un único beneficio, pero es uno grande. Al usarlo, puede administre paquetes sin tener que tocar el código en absoluto. Esto significa que puede realizar cambios sin recompilar, lo que facilita las implementaciones rápidas. Además, significa que su desarrollador front-end, que va a estar más familiarizado con los archivos que se deben incluir, puede definir los paquetes sin tener que trabajar con ningún código de back-end.

Sin embargo, hay bastantes limitaciones sobre lo que puede especificar en el Paquete.config. Por ejemplo, no puede especificar ninguna transformación personalizada para ser aplicado a artículos individuales o paquetes. Las únicas propiedades de paquete que puedes establecer son las Path, CdnPath, y CdnFallbackExpression. No puede establecer las propiedades Orderer o EnableFileExtensionReplacements. No tiene una manera de incluir un directorio que incluya todos los subdirectorios (como puede hacerlo con el método IncludeDirectory). Básicamente, hay una GRAN cantidad de funcionalidad que solo está disponible a través del código de back-end. Concedido, mucho de esto se podría establecer mediante el uso de código de back-end para recuperar un paquete que se definió en el paquete.config, y luego manipulando. Pero si vas a hacer eso, también podrías crear el paquete en el back-end.

Mi filosofía personal es usar bundle.config a menos que necesite hacer algo con el paquete que no sea posible de esa manera. Sin embargo, estoy de acuerdo en que tenerlos a todos en un solo lugar es ideal. Si decido que necesito usar la clase, entonces usaré eso para todos de mis paquetes de ese tipo (a veces pongo mis paquetes JS en la clase y mis paquetes CSS en el .archivo de configuración, aunque). Sin embargo, estoy seguro de que algunas personas completamente razonables no estarían de acuerdo con ese proceso.

¿Puede alguien explicar la diferencia en el uso de los recursos agrupados usando el BundleConfig.cs class file en oposición al bundle.config archivo xml?

La diferencia es que tendrías que leer, analizar y cargar el contenido del paquete.config en tiempo de ejecución. Por lo tanto, usando BundleConfig.cs archivo de clase podría ser más simple.

1) ¿por qué no solo hacer los dos de una manera particular para la simplicidad

Totalmente de acuerdo.

2) por qué ¿alguien preferiría codificar recursos como ese en un archivo de clase?

En pocas palabras: fácil de entender.

Parece un enfoque mucho más dinámico simplemente ponerlos en un xml archivo que se puede cambiar sobre la marcha si es necesario.

Sí, pero tiene que escribir más código para detectar cuando ocurren cambios y luego agregar/eliminar/reemplazar la configuración existente. Si se hace mal, podría provocar problemas de interfaz de usuario en tiempo de ejecución.

También, si hay alguna real documentación sobre el Sistema.Web.Optimización, I me encantaría saber la ubicación (porque estoy seguro de que no puedo encontrarlo).

Ya contestado arriba, pero yo repetiría: http://www.asp.net/mvc/tutorials/mvc-4/bundling-and-minification