如何在多个环境中管理ASP.NET Core bundleconfig.json? [英] How to manage ASP.NET Core bundleconfig.json for multiple environments?

问题描述

在开发环境和生产环境中使用ASP.NET Core bundleconfig.json的最佳实践是什么?先前的捆绑程序( BundleCollection )将注意DEBUG编译器指令，并且在调试时不会缩小脚本列表.

What's the best practice for using the ASP.NET Core bundleconfig.json with development versus production environments? The prior bundler (BundleCollection) would pay attention to the DEBUG compiler directive and not minify the list of scripts when you're debugging.

似乎新的范例是在HTML模板中具有<environment>标记，以测试ASPNETCORE_ENVIRONMENT值.尽管我看不到将环境变量合并到bundleconfig.json工作流程中的方法.

It appears as though the new paradigm is to have <environment> tags in the HTML templates that test for the ASPNETCORE_ENVIRONMENT value. Though I don't see a way of incorporating that environment variable into the bundleconfig.json workflow.

我看到的一种方法是为bundleconfig.json(最小和非最小版本)中的每个捆绑软件输出维护2个列表，以便可以调试JavaScript.或者，我可以在开发<environment>标记中放置指向未捆绑JavaScript的直接链接，然后在生产/登台<environment>标记中引用捆绑并缩小的版本.

One way I see is to maintain 2 lists for each bundle output in bundleconfig.json, minified and non-minified versions, so that the JavaScript can be debugged. Alternatively I could put direct links to the unbundled JavaScript in the development <environment> tag and then reference the bundled and minified version in the production/staging <environment> tag.

无论哪种方式，都需要维护2个JavaScript文件列表(所有这些都适用于CSS文件).这对我来说似乎是倒退了一步，在此之前，您只需要维护一个源文件列表，BundleCollection只会在适当的时候缩小.

Either way there's a need to maintain 2 lists of JavaScript files (and all this goes for CSS files as well). That seems like a step backwards to me, where before you only needed to maintain a single list of source files and the the BundleCollection would only minify when appropriate.

我是否在这里遗漏了一些东西，还是需要进一步调查Gulp才能处理不同的环境?

Am I missing something here or do I need to go a step further and investigate Gulp to be able to handle the different environments?

推荐答案

我想我找到了答案.我正准备创建一个HTML帮助程序来读取开发环境的bundleconfig.json，但看来我不是第一个认为这是个好主意的人.请注意，.NET Core实现链接到页面底部

I think I found my answer. I was about to create an HTML helper to read the bundleconfig.json for the development environment, but it appears I'm not the first one to think this was a good idea. Note that the .NET Core implementation is linked to at the bottom of the page

https://github.com/madskristensen/BundlerMinifier/wiki/拆包调试脚本

修改

对于.NET Core实施，对bundleconfig.json的引用期望它位于/Configs文件夹中，在您的项目中可能会或可能不会.对我来说，我只是将它放在项目的根目录中.

For the .NET Core implementation, the reference to the bundleconfig.json was expecting it to be in a /Configs folder, which may or may not be the case in your project. For me, I just had it in the root of the project.

修改

因此，如果源文件位于wwwroot文件夹之外，则此操作将无效.将文件放在wwwroot文件夹之外是完全合理的，因此我正在研究让html helper指向将在调试模式下流式传输文件的路径

So this doesn't work if the source files are outside of the wwwroot folder. Having files outside of the wwwroot folder is completely reasonable, so I'm investigating having the html helper point to a path that will stream the files in debug mode

可能的解决方案

这是我对解决方案的改进:

Here's my evolution of the solution:

https://gist.github.com/rupe120/512a9eb837383963f80fd9ef4984eb15

更新

我修改了解决方案以在路由定义中使用{*filePath}，因此现在无需对路径进行编码

I modified my solution to use {*filePath} in the route definition, so there's now no need to encode the path

更新

我认为这是我要做的最后一次重大更新.我用bundleconfig.json中的outputFileName值替换了静态基本路由字符串.因此，现在调试路径与最小化文件一样多，而不必担心名称冲突.另外，在调试时，您可以查看哪个包中包含哪些文件，我认为这很酷.

I think this is the last major update I'll do. I replaced the static base route string with the outputFileName values from the bundleconfig.json. So now there's as many debug routes as there will be minified files and no fear what so ever of name collisions. Additionally you can see what files are included in which bundle when you're debugging, which I think is pretty cool.

这篇关于如何在多个环境中管理ASP.NET Core bundleconfig.json?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！