在 ASP.NET 4.5 WebForms 中通过 bundle.config 与 BundleConfig.cs 捆绑资源答案

【问题标题】：Bundling resources via bundle.config vs BundleConfig.cs in ASP.NET 4.5 WebForms在 ASP.NET 4.5 WebForms 中通过 bundle.config 与 BundleConfig.cs 捆绑资源
【发布时间】：2012-11-23 11:58:03
【问题描述】：

关于 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 和css 在bundle.config 中的捆绑。

我想我不明白#1) 为什么你不会为了简单起见而只用一种特定的方式来做它们 - 以及 #2) 为什么有人更愿意在类文件中硬编码这样的资源？将它们放在一个 xml 文件中似乎是一种更加动态的方法，如果需要，可以随时更改。

似乎更多的文章实际上倾向于使用 BundleConfig.cs。是否有一些特别的优点或缺点鼓励这样做？

另外，如果有任何关于 System.Web.Optimization 的真实文档，我很想知道位置（因为我肯定找不到）。

谢谢-

【问题讨论】：

我看到您将此标记为已回答，但我发现您标记的答案并未真正回答问题。我已经阅读了这篇文章及其包含的链接，但它没有解释为什么你会在配置文件上使用类文件，反之亦然。我是否遗漏了文章或链接中的某些内容？
好吧..说实话，我不知道它真的做到了 100%。我基本上认为它的意思是使用该类允许框架执行更多动态的事情，例如基于调试从缩小到非缩小交换、替换 {version} 等。而 xml 文件更静态。但我实际上并没有花时间来检验这个理论，因为我最终走向了不同的方向。 CSS 是我主要对捆绑和缩小感兴趣的东西，我现在基本上是通过 Web Essentials 插件和 LESS @import's 来做这件事的。
不，这不是真的。对自动交换缩小文件和使用 {version} 占位符的支持也适用于 bundle.config 文件。实际上，框架会在应用程序首次启动时解析 bundle.config，并且只调用您将在类中使用的相同方法，并传入它从 .config 文件中读取的值。

标签： asp.net webforms asp.net-4.5

【解决方案1】：

本文档比我以往任何时候都更好地解释了这一切

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），仅由智能感知。

【讨论】：

问题是关于 ASP.Net WebForms 但你给了他一个指向 ASP.Net MVC 的链接。它们有不同的 API 和不同的捆绑方式。而且，正如 Elezar 所说，你根本没有真正回答这个问题。

【解决方案2】：

谁能解释一下捆绑资源使用的区别使用 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

【讨论】：

您不需要编写代码来检测更改、添加/删除/替换或解析 .config 文件。该框架会为您做到这一点。另外，我个人认为包含所有资源的单个 XML 文件比指定它们的代码更容易理解。

【解决方案3】：

据我所知，接受的答案实际上根本没有回答问题。它讨论了捆绑框架的好处，但没有讨论使用 BundleConfig.cs 与使用 bundle.config 文件有何不同。

这很大程度上取决于您是更喜欢使用代码还是使用标记，但每种方法都有一些特定于该方法的优点。

对于 bundle.config，实际上只有一个好处，但它是一个很大的好处。通过使用它，您可以管理捆绑包，而无需完全接触代码。这意味着您可以在不重新编译的情况下进行更改，从而更轻松地进行快速部署。此外，这意味着最熟悉应该捆绑的文件的前端开发人员可以定义捆绑包，而无需使用任何后端代码。

但是，您可以在 Bundle.config 中指定的内容有很多限制。例如，您不能指定要应用于单个项目或捆绑包的任何自定义转换。您可以设置的唯一捆绑属性是Path、CdnPath 和CdnFallbackExpression。您不能设置 Orderer 或 EnableFileExtensionReplacements 属性。您无法包含包含所有子目录的目录（就像您可以使用 IncludeDirectory 方法一样）。基本上，有很多功能只能通过后端代码使用。当然，您可以通过使用后端代码检索在 bundle.config 中定义的捆绑包，然后进行操作来设置其中的很多内容。但如果你打算这样做，你也可以在后端创建捆绑包。

我个人的理念是使用 bundle.config，除非我需要对 bundle 做一些不可能的事情。但是，我确实同意将它们全部放在一个地方是理想的。如果我决定需要使用该类，那么我将把它用于我的那种类型的 all 包（我有时将我的 JS 包放在类中，将我的 CSS 包放在 .config文件，但）。不过，我敢肯定，一些完全通情达理的人会不同意这个过程。

【讨论】：

配置文件被视为后端代码。我已经得到许多前端开发人员的证实，他们认为浏览器无法访问的任何东西都是后端资产。
此外，显式编写代码可以让您准确了解代码何时执行、设置断点、检查输入、输出和其他环境变量。建议使用 bundle.config，但代码更灵活（放在 IF/ELSE 中），甚至可测试。
@Believe2014 - 更重要的是它是一个后端资产文件，包含前端开发人员想要访问的前端资产 (JS/CSS) 的信息。它也是用前端开发人员熟悉（或比 C# 或 VB 更熟悉）的语言编写的。
我们遵循“.cs 由开发人员控制”而“.config 可由系统管理员使用”的理念，即系统管理员是否需要更改 *.config为他们提供了一种无需联系开发人员/重新编译/重新发布即可进行更改的方式
仅供参考，看来没有正确呈现 Bundle.config 中的 scriptBundle 引用。它似乎应用了 Styles.Render 而不是 Scripts.Render。所以你需要使用强制它