关于ASP.NET 4.5的新System.Web.Optimization / Microsoft.AspNet.Web.Optimization：
有人能解释使用 BundleConfig.cs 类文件而不是 bundle.config xml文件使用捆绑资源的区别吗？
我看到一些articles显示捆绑了BundleConfig.cs中的js和css，而others显示了BundleConfig.cs中的捆绑js和bundle.config中的css。
我想我不明白＃1）为什么你不会为了简单而以一种特殊的方式做到这一点 - 以及＃2）为什么有人宁愿在类文件中对这些资源进行硬编码？将它们放在一个xml文件中似乎是一种更加动态的方法，可以在必要时即时更改。
似乎更多的文章实际上倾向于使用BundleConfig.cs而不是其他任何东西。是否有一些特别的赞成或赞成鼓励这个？
另外，如果有关于System.Web.Optimization的任何真实文档，我很想知道位置（因为我肯定找不到它）。
谢谢 -
答案 0 :(得分：22)
据我所知，接受的答案实际上并没有回答这个问题。它讨论了捆绑框架的好处，但没有讨论使用BundleConfig.cs与使用bundle.config文件的不同。
很多原因归结为您是喜欢使用代码还是使用标记，但每个都有一些特定于该方法的专业人员。
对于bundle.config，实际上只有一个好处，但它是一个很大的好处。通过使用它，您可以管理捆绑包而无需触摸代码。这意味着您无需重新编译即可进行更改，从而使快速部署变得更加容易。此外，这意味着您最熟悉应该捆绑的文件的前端开发人员可以定义捆绑包，而无需使用任何后端代码。
但是，您在Bundle.config中可以指定的内容有很多限制。例如，您无法指定要应用于单个项目或包的任何自定义转换。您能够设置的唯一捆绑属性是Path，CdnPath和CdnFallbackExpression。您无法设置Orderer或EnableFileExtensionReplacements属性。您无法包含包含所有子目录的目录（就像使用IncludeDirectory方法一样）。基本上，有很多功能只能通过后端代码获得。当然，通过使用后端代码来检索bundle.config中定义的包，然后进行操作，可以设置很多这样的功能。但是如果你打算这样做，你也可以在后端创建捆绑包。
我个人的理念是使用bundle.config，除非我需要对那些不可能的bundle做一些事情。但是，我确实同意将它们放在一个地方是理想的。如果我决定需要使用该类，那么我将把它用于所有我的类型的包（我有时会将我的JS包放在类中，而我的CSS包放在.config中）虽然文件。不过，我确信一些完全合理的人不同意这个过程。
答案 1 :(得分：6)
这篇文章比我更好地解释了这一切
http://www.asp.net/mvc/tutorials/mvc-4/bundling-and-minification
最好的事情之一是：
捆绑框架遵循几个常见的约定，例如：
当“FileX.min.js”和“FileX.js”选择“.min”文件以供发布 存在。
选择非“.min”版本进行调试。忽略“-vsdoc” 文件（例如jquery-1.7.1-vsdoc.js），仅供使用 智能感知。
答案 2 :(得分：6)
任何人都可以解释捆绑资源使用的差异 使用BundleConfig.cs类文件而不是bundle.config xml文件？
不同之处在于您必须在运行时读取，解析和加载bundle.config的内容。因此，使用BundleConfig.cs类文件可能更简单。
1）为什么你不会为了简单而以一种特殊的方式做这些事情
完全同意。
2）为什么有人愿意在类文件中硬编码资源？
简单地说：易于理解。
将它们放入xml中似乎是一种更加动态的方法 可以在必要时即时更改的文件。
是的，但您必须编写更多代码来检测更改何时发生，然后添加/删除/替换现有设置。如果做得不好，可能会在运行时导致UI问题。
另外，如果有关于System.Web.Optimization的任何真实文档，我 我很想知道这个位置（因为我肯定无法找到它）。
上面已经回答过，但我会重复：http://www.asp.net/mvc/tutorials/mvc-4/bundling-and-minification