Azure 上 JavaScript 文件的策略
我正在制定在 Azure 上存储和部署 JavaScript 文件的策略（ASP.NET Web 角色） 我的要求是：
- 在生产中使用缩小版本
- 在开发环境中使用原始版本（即未缩小）本地版本（以简化调试）
- 简单的构建/部署过程（VS2010）
- 简单的更新过程（我的文件会不时更改） ）
这里有一个很好的讨论Visual Studio 2010：发布缩小的 javascript 文件而不是原始的，但是这没有考虑 Azure 可以提供的好处或使用多个实例的好处。
我正在考虑将缩小的 JavaScript 文件部署到 blob 存储并在生产版本中使用它们。这些将使用大型 max-age 缓存控件进行存储，以进行客户端缓存，文件名将存储版本（以便我可以轻松更新）。我欢迎对此策略的反馈。
因此，在开发中，呈现的 HTML 将引用本地脚本文件，即：
<script src="Scripts/myjavascript-0.0.1.js" type="text/javascript"></script>
但在生产中，结果应使用以下内容来引用缩小版本。
<script src="http://myblob.blob.core.windows.net/Scripts/myjavascript-0.0.1.js" type="text/javascript"></script>
我的主要问题是如何最好地实现开发和生产路径的自动切换。或者自定义处理程序是否是正常路由（如果是这样，那将如何工作 – 我不希望每个实例在每个请求时从 blob 重新加载）。
I am working on a strategy for storing and deploying JavaScript files on Azure (ASP.NET web role)
My requirements are:
- To use minified versions in production
- Use original versions (i.e. not minified) local versions in development environment (to simplify debugging)
- Simple build/deployment process (VS2010)
- Simple update process (my files will change from time-to-time)
There is a great discussion here Visual Studio 2010: Publish minified javascript files instead of the original ones however this does not take into account the benefits Azure can offer or working with multiple instances.
I am considering deploying my minified JavaScript files to blob storage and use these in the production version. These will be stored with a large max-age Cache Control for client side caching and filenames will store the version (so I can easily update). I welcome feedback on this strategy.
Thus, in development the rendered HTML would refer to a local script file, i.e.:
<script src="Scripts/myjavascript-0.0.1.js" type="text/javascript"></script>
But in Production the result should use the following to refer to a minified version.
<script src="http://myblob.blob.core.windows.net/Scripts/myjavascript-0.0.1.js" type="text/javascript"></script>
My main question though is how to best to achieve automatic switching of the paths in development and production. Or would a custom handler be the normal route (and if so how would that work – I don’t want each instance to reload from the blob on each request).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
关于#1 & 2：
我在此处讨论了此策略。基本思想是使用辅助函数来发出脚本标签。该函数可以在调试模式下构建到调试文件的链接，否则可以构建到缩小文件的链接（这也使得使用缩小文件进行本地测试变得容易）。相同的函数可以处理向路径添加版本以使缓存失效等。
关于#3：
将缩小添加为构建后步骤。我将其添加到我的
csproj（这只是一个 msbuild 文件）中，它使用 yui-compressor：这将创建缩小的
*-min.js和*- min.css文件分别位于 ~\Scripts 和 ~\Styles 中。警告 B/c 版本 2.4.6 中的错误 yui 压缩器，如果目录中只有一个
.css或.js文件，则上述操作将不起作用。Regarding #1 & 2:
I discuss a strategy for this here. The basic idea is to user a helper function to emit the script tag. The function can construct a link to the debug files when in debug mode, and the minified files otherwise (which also makes it easy to test locally with the minified files). The same function can handle adding a version to the path for cache invalidation, etc.
Regarding #3:
Add the minification as an after-build step. I added this to my
csproj(which is just an msbuild file), which use yui-compressor:This will create minified
*-min.jsand*-min.cssfiles in ~\Scripts and ~\Styles, respectively.Warning B/c of a bug in version 2.4.6 of the yui compressor, the above won't work if there is only one
.cssor.jsfile in the directory.你的基本计划听起来不错。它甚至可以让您轻松地使用 CDN（您只需将存储帐户的路径替换为 CDN 的路径）。
我不认为我会想太多。正如其他地方所建议的，控件是一个好方法。只需让此控件查找 web.config 设置即可获取脚本的根目录并将其添加到脚本的路径前面（您的本地版本此设置将为空）。为了确保您不必为每次部署更改配置，我将使用 配置转换，因此它会自动发生。
Your basic plan sounds good. It will even enable you to make use of the CDN with very little effort (you just need to replace the path to your storage account with the path to the CDN).
I don't think I'd try to over think this too much. As suggested elsewhere a control is a good way to go. Simply have this control look up a web.config setting to get the root directory for your scripts and prepend it to the path of the script (your local version this setting would be empty). In order to make sure that you don't have to mess around changing the config for every deploy, I'd use config transformations so it just happens automatically.
为了在从 Azure 运行时动态切换脚本链接的 URL，您应该将所有脚本块放入用户控件中，并在所有页面中使用该用户控件。您不应将脚本链接直接放在 aspx/master 页面上，而应放在 ascx 上并使用 ascx。这有助于将常见脚本链接保留在单个文件中，并且当您需要进行站点范围内的更改时，只需更改 ascx.txt 文件即可。
另一种方法是使用我的 httphandler 将脚本的 URL 从相对 URL 更改为绝对 URL，以便于从与站点运行所在的不同域下载脚本。当然，您可以使用它来添加 Azure 站点的绝对 URL。
For switching the URL of the script links dynamically when running from Azure, you should put all the script blocks inside a usercontrol and use that usercontrol in all the pages. You should not put the script links directly on the aspx/master pages, instead put then on ascx and use the ascx. This helps keeping common script links in a single file and when you need to make a sitewide change, you just change the ascx.
Another approach is to use my httphandler that changes the URL of the scripts from relative to absolute in order to facilitate download of scripts from different domain than the site is running from. You can of course use it to prepend the absolute URL of your Azure site.
http://omaralzabir.com/loading_static_content_in_asp_net_pages_from_different_domain_for_faster_parallel_download/
您可能想查看 Windows Azure CDN 帮助程序项目。它几乎应该可以完成您所要求的一切。如果您希望缩小的文件自动部署到 blob 存储或保留在 Web 角色上，您可以在配置中进行设置。
You may want to check out the Windows Azure CDN helpers project. It should do pretty much everything you are asking for. You can set in the config if you want your minified files to automatically be deployed to blob storage or stay on the web roles.