asp.net - studio - bundles asp net webforms

Agrupación de recursos a través de bundle.config vs BundleConfig.cs en ASP.NET 4.5 WebForms

Question

Con respecto a la nueva System.Web.Optimization / Microsoft.AspNet.Web.Optimization de ASP.NET 4.5:

¿Alguien puede explicar la diferencia en el uso de paquetes de recursos usando el archivo de clase BundleConfig.cs en lugar del archivo bundle.config xml?

He visto algunos artículos que muestran paquetes de js y css en BundleConfig.cs, mientras que otros muestran paquetes js en BundleConfig.cs y css en bundle.config.

Supongo que no entiendo # 1) por qué no solo los haría de una manera particular por simplicidad, y # 2) ¿por qué alguien preferiría codificar recursos como ese en un archivo de clase? Parece un enfoque mucho más dinámico para simplemente ponerlos en un archivo xml que se puede cambiar sobre la marcha si es necesario.

Parece que hay más artículos que realmente se inclinan por utilizar BundleConfig.cs que cualquier otra cosa. ¿Hay algún pro o estafa particular que fomente esto?

Además, si hay alguna documentación real sobre System.Web.Optimization, me gustaría saber la ubicación (porque seguro que no puedo encontrarla).

Gracias-

Answer 1

Hasta donde puedo decir, la respuesta aceptada en realidad no responde la pregunta en absoluto. Discute los beneficios de la estructura de agrupamiento, pero no cómo el uso de BundleConfig.cs es diferente que usar el archivo bundle.config.

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 para ese método.

Para bundle.config, en realidad solo hay un beneficio único, pero es muy grande. Al usarlo, puede administrar paquetes sin tener que tocar el código en absoluto. Esto significa que puede hacer cambios sin volver a compilar, facilitando las implementaciones rápidas. Además, significa que su desarrollador front-end, que estará más familiarizado con los archivos que deben agruparse, puede definir los paquetes sin tener que trabajar con ningún código de back-end.

Sin embargo, existen bastantes limitaciones sobre lo que puede especificar en Bundle.config. Por ejemplo, no puede especificar ninguna transformación personalizada para aplicar a elementos individuales o paquetes. Las únicas propiedades del paquete que puede establecer son Path , CdnPath y CdnFallbackExpression . No puede establecer las propiedades Orderer o EnableFileExtensionReplacements . No tiene forma de incluir un directorio que incluya todos los subdirectorios (como puede IncludeDirectory con el método IncludeDirectory ). Básicamente, hay MUCHAS funcionalidades que solo están disponibles a través del código de back-end. De acuerdo, mucho de esto podría establecerse mediante el uso de código de fondo para recuperar un paquete definido en bundle.config y luego manipularlo. 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 deba 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, la usaré para todos mis paquetes de ese tipo (aunque a veces pongo mis paquetes de JS en la clase y mis paquetes de CSS en el archivo .config). Sin embargo, estoy seguro de que algunas personas completamente razonables estarían en desacuerdo con ese proceso.

Answer 2

esta documentación lo explica todo mejor de lo que pude

http://www.asp.net/mvc/tutorials/mvc-4/bundling-and-minification

Una de las mejores cosas es esta:

El marco de agrupamiento sigue varias convenciones comunes tales como:

Seleccionando el archivo ".min" para liberar cuando existen "FileX.min.js" y "FileX.js".

Seleccionar la versión que no es ".min" para la depuración. Ignorando los archivos "-vsdoc" (como jquery-1.7.1-vsdoc.js), que solo utiliza IntelliSense.

Answer 3

¿Alguien puede explicar la diferencia en el uso de paquetes de recursos usando el archivo de clase BundleConfig.cs en lugar del archivo bundle.config xml?

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

1) por qué no solo los harías a ambos de una manera particular por 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 para simplemente ponerlos en un archivo xml que se puede cambiar sobre la marcha si es necesario.

Sí, pero debe escribir más código para detectar cuándo ocurren los cambios y luego agregar / eliminar / reemplazar la configuración existente. Si se hace mal, podría ocasionar problemas de UI en tiempo de ejecución.

Además, si hay alguna documentación real sobre System.Web.Optimization, me gustaría saber la ubicación (porque seguro que no puedo encontrarla).

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