Regroupement des ressources via bundle.config vs BundleConfig.cs dans ASP.NET 4.5 WebForms
Concernant le nouveau System.Web.Optimization/Microsoft.AspNet.Web.Optimization d'ASP.NET 4.5:
Quelqu'un peut-il expliquer la différence dans l'utilisation des ressources de regroupement à l'aide du fichier de classe BundleConfig.cs par opposition au fichier .config Fichier xml?
J'ai vu certains articles montrant le regroupement de js et css dans BundleConfig.cs, tandis que autres montrant le regroupement de js dans BundleConfig.cs et css dans bundle.config.
Je suppose que je ne comprends pas # 1) pourquoi vous ne feriez pas simplement les deux d'une manière particulière pour la simplicité - et # 2) pourquoi quelqu'un préférerait coder en dur des ressources comme celle-ci dans un fichier de classe? Cela semble être une approche beaucoup plus dynamique de simplement les mettre dans un fichier xml qui peut être modifié à la volée si nécessaire.
Il semble que plus d'articles soient réellement tournés vers l'utilisation de BundleConfig.cs qu'autre chose. Y a-t-il des avantages ou des inconvénients particuliers qui encouragent cela?
De plus, s'il existe une véritable documentation sur System.Web.Optimization, j'aimerais connaître l'emplacement (car je ne le trouve certainement pas).
Merci-
cette documentation l'explique mieux que jamais
http://www.asp.net/mvc/tutorials/mvc-4/bundling-and-minification
L'une des plus belles choses est la suivante:
Le cadre de regroupement suit plusieurs conventions communes telles que:
Sélection du fichier ".min" pour publication lorsque "FileX.min.js" et "FileX.js" existent.
Sélection de la version non ".min" pour le débogage. Ignorer les fichiers "-vsdoc" (tels que jquery-1.7.1-vsdoc.js), qui sont utilisés uniquement par IntelliSense.
Pour autant que je sache, la réponse acceptée ne répond pas du tout à la question. Il présente les avantages du cadre de regroupement, mais pas en quoi l'utilisation de BundleConfig.cs est différente de l'utilisation du fichier bundle.config.
Cela dépend en grande partie du fait que vous préfériez travailler en code ou en balisage, mais chacun a des avantages spécifiques à cette méthode.
Pour le bundle.config, il n'y a vraiment qu'un seul avantage, mais c'est un gros avantage. En l'utilisant, vous pouvez gérer des offres groupées sans avoir à toucher du tout à du code. Cela signifie que vous pouvez apporter des modifications sans recompiler, ce qui facilite les déploiements rapides. Cela signifie également que votre développeur frontal, qui connaîtra le mieux les fichiers à regrouper, peut définir les regroupements sans avoir à utiliser de code principal.
Cependant, il y a quelques limitations sur ce que vous pouvez spécifier dans Bundle.config. Par exemple, vous ne pouvez pas spécifier de transformations personnalisées à appliquer à des éléments individuels ou à des ensembles. Les seules propriétés d'ensemble que vous pouvez définir sont les Path, CdnPath et CdnFallbackExpression. Vous ne pouvez pas définir les propriétés Orderer ou EnableFileExtensionReplacements. Vous n'avez aucun moyen d'inclure un répertoire comprenant tous les sous-répertoires (comme vous pouvez le faire avec la méthode IncludeDirectory). Fondamentalement, il y a BEAUCOUP de fonctionnalités qui ne sont disponibles que via le code principal. Certes, vous pouvez définir une grande partie de cela en utilisant du code principal pour récupérer un ensemble défini dans le bundle.config, puis en le manipulant. Mais si vous voulez le faire, vous pouvez également créer le bundle dans le back-end.
Ma philosophie personnelle est d'utiliser bundle.config sauf si j'ai besoin de faire quelque chose avec le bundle qui n'est pas possible de cette façon. Cependant, je suis d'accord que les avoir tous au même endroit est idéal. Si je décide que je dois utiliser la classe, je l'utilise pour tous de mes bundles de ce type (je mets parfois mes bundles JS dans la classe et mes bundles CSS dans le .config fichier, cependant). Je suis sûr que certaines personnes tout à fait raisonnables seraient en désaccord avec ce processus.
Quelqu'un peut-il expliquer la différence dans l'utilisation des ressources de regroupement à l'aide du fichier de classe BundleConfig.cs par opposition au fichier xml bundle.config?
La différence est que vous devrez lire, analyser et charger le contenu du bundle.config au moment de l'exécution. Par conséquent, l'utilisation du fichier de classe BundleConfig.cs pourrait être plus simple.
1) pourquoi vous ne feriez pas simplement les deux d'une manière particulière pour plus de simplicité
Entièrement d'accord.
2) Pourquoi quelqu'un préférerait-il coder en dur des ressources comme celle-ci dans un fichier de classe?
Autrement dit: facile à comprendre.
Cela semble être une approche beaucoup plus dynamique de simplement les mettre dans un fichier xml qui peut être modifié à la volée si nécessaire.
Oui, mais vous devez écrire plus de code pour détecter les changements, puis ajouter/supprimer/remplacer la configuration existante. Si mal fait, cela pourrait entraîner des problèmes d'interface lors de l'exécution.
De plus, s'il existe une véritable documentation sur System.Web.Optimization, j'aimerais connaître l'emplacement (car je ne le trouve certainement pas).
Déjà répondu ci-dessus, mais je répéterais: http://www.asp.net/mvc/tutorials/mvc-4/bundling-and-minification