🤜🏻 👨🏿‍🤝‍👨🏾 🐬 Bundle Transformer：Summer Update 🤵🏽 🕳️ 🍒

昨年9月、 MSIE JavaScript Engine for .NETライブラリがJavaScript Engine Switcherライブラリに置き換えられ、 BundleTransformer.CleanCssモジュールが作成されて以来、Bundle Transformerに実質的な革命的な変更はありませんでした。変更は主に進化的でした：ミニマライザーとトランスレーターの新しいバージョン（プロジェクトでの作業の中で最も日常的で難しい部分）のサポートが追加され、マイナーなバグが修正され、生産性を高めるための作業が継続されました。

しかし、この夏はすべてが変わりました。5月末から7月にかけて、Bundle Transformerユーザーからプロジェクトを改善するための膨大な数の推奨事項が寄せられました。それらのほとんどはバージョン1.9.0およびその後の夏の更新で実装されました。この記事では、それらのうち最も重要なものを検討します。

クラスStyleTransformerおよびScriptTransformer

System.Web.Optimizationの CssMinifyおよびJsMinifyとの類推によって名前が選択されたため、 CssTransformerは、 CssTransformerおよびJsTransformerクラスに完全に成功した名前は選択されませんでした。 ScriptBundleクラスとScriptBundleクラスがSystem.Web.Optimizationに登場したとき、これらの名前は価値がないことが明らかになりました。

私はこれらのクラスの名前変更を長い間遅らせましたが、バージョン1.9.0で作業しているときに、すべて同じ名前に変更することにしました。現在、それらはStyleTransformerおよびScriptTransformerと呼ばれています。古いCssTransformerおよびJsTransformerクラスはカーネルで引き続き使用できます（新しいクラスのラッパーとして実装さObsoleteます）が、 Obsoleteれたと見なされ（ Obsolete属性でマーク）、バージョン2.0.0で削除されます。

ポストプロセッサー

5月下旬に、Vegard Larsen（ノルウェーの会社Digital Creationsの従業員）からプルリクエスト「Autoprefixerのサポート」を受け取りました。コードを見ると、現在のBundle Transformerアーキテクチャがそのようなモジュールの実装に適していないことがすぐに明らかになりました。 Vegardは、このモジュールの機能をスタイルトランスレーターの形式で実装しました。これは、他のすべてのトランスレーター（LESS、Sassなど）の後に実行されることになっています。この実装全体がハッキングのように見えたため、このプルリクエストを拒否することにしました。その結果、VegardはNuGetでモジュールの非公式バージョンであるBundleTransformer.Autoprefixer.Unofficialを公開し、新しいBundle Transformerアーキテクチャの作業を開始しました。

新しいタイプのモジュールが必要でした。これは、トランスレーターの後、ミニマイザーの前に起動する必要があり、そのようなモジュールを呼び出す回数と順序は開発者が決定する必要があります。新しいタイプのモジュールの名前として、Andrei Sitnikによって造られた用語「ポストプロセッサー」を使用することにしました（Andrei Sitnikが誰であるか、またはポストプロセッサーが何であるかわからない場合は、Frontflipポッドキャストの第6号を聞くことをお勧めします）。

Bundle TransformerのポストIPostProcessorは、 IPostProcessorインターフェイスを実装するクラス、またはBundleTransformer.Core.PostProcessors名前空間からPostProcessorBase基本クラスを継承するクラスにBundleTransformer.Core.PostProcessorsます。他のタイプのモジュール（アダプター）と同様に、ポストプロセッサーはWeb.configファイルに登録する必要があります。例として、CSSポストプロセッサーを使用した登録プロセスを検討してください。

 <configuration> … <bundleTransformer xmlns="http://tempuri.org/BundleTransformer.Configuration.xsd"> <core …> <css defaultPostProcessors="UrlRewritingCssPostProcessor,AutoprefixCssPostProcessor" …> <postProcessors> <add name="UrlRewritingCssPostProcessor" type="BundleTransformer.Core.PostProcessors.UrlRewritingCssPostProcessor, BundleTransformer.Core" useInDebugMode="false" /> <add name="AutoprefixCssPostProcessor" type="BundleTransformer.Autoprefixer.PostProcessors.AutoprefixCssPostProcessor, BundleTransformer.Autoprefixer" useInDebugMode="true" /> </postProcessors> </css> … </core> … </bundleTransformer> … </configuration>

2つのポスト/configuration/bundleTransformer/core/css/postProcessorsが/configuration/bundleTransformer/core/css/postProcessors登録されてい/configuration/bundleTransformer/core/css/postProcessors ：

UrlRewritingCssPostProcessor。 相対パスを絶対パスに変換します（ポストプロセッサとして実装された標準のバンドルトランスフォーマー機能）。
AutoprefixCssPostProcessor。 Bundle TransformerにAutoprefixerサポートを追加します。

一見、これはdefaultMinifier登録に非常に似ていますが、わずかな違いが1つあります： /configuration/bundleTransformer/core/css要素のdefaultMinifier属性でdefaultMinifier 1つだけ指定できる場合、 defaultMinifier属性で任意の数のポストdefaultPostProcessorsを指定できます（ゼロでも））さらに、この属性でポストプロセッサの名前を指定する順序によって、ポストプロセッサが実行される順序が決まります。属性が欠落している場合、 UrlRewritingCssPostProcessorデフォルトのUrlRewritingCssPostProcessor使用されます。

また、このコードは、ポストuseInDebugMode属性の値が異なることを示しています： UrlRewritingCssPostProcessor場合はfalse （すべてのファイルが1つに結合されるリリースモードでのみ絶対パスへの相対パスの変換が必要です）、およびAutoprefixCssPostProcessorはtrue （ベンダープレフィックスの更新も必要です）デバッグモード、リリースモード）。

JavaScriptポスト/configuration/bundleTransformer/core/js登録は、構成要素/configuration/bundleTransformer/core/jsで行わなければならないことを除いて、CSSポスト/configuration/bundleTransformer/core/js登録と実質的に違いはありません。

強化されたデバッグHTTPハンドラー

通常、ほとんどのBundle Transformerユーザーは宣言的な方法で（ Web.configを介して）モジュールを構成しますが、場合によっては命令的なアプローチが必要です。たとえば、LESS変数を使用する場合：

 using System.Collections.Generic; using System.Web.Optimization; using BundleTransformer.Core.Builders; using BundleTransformer.Core.Orderers; using BundleTransformer.Core.Transformers; using BundleTransformer.Core.Translators; using BundleTransformer.Less.Translators; public class BundleConfig { public static void RegisterBundles(BundleCollection bundles) { var nullBuilder = new NullBuilder(); var nullOrderer = new NullOrderer(); var lessTranslator = new LessTranslator { GlobalVariables = "my-variable='Hurrah!'", ModifyVariables = "font-family-base='Comic Sans MS';body-bg=lime;font-size-h1=50px" }; var styleTransformer = new StyleTransformer( new List<ITranslator> { lessTranslator }); var commonStylesBundle = new Bundle("~/Bundles/BootstrapStyles"); commonStylesBundle.Include("~/Content/bootstrap/bootstrap.less"); commonStylesBundle.Builder = nullBuilder; commonStylesBundle.Transforms.Add(styleTransformer); commonStylesBundle.Orderer = nullOrderer; bundles.Add(commonStylesBundle); } }

上記のコードでは、 LessTranslatorクラスのインスタンスを明示的に作成し、 ModifyVariablesとModifyVariablesを使用してLESS変数を構成します。このアプローチを使用すると、外部ソース（データベースなど）から取得したLESS変数の値をトランスレーターに渡すことができます。

LESS変数を操作する2番目の方法があります。最初に、カスタム要素変換を作成する必要があります。

 using System.Text; using System.Web.Optimization; public sealed class InjectContentItemTransform : IItemTransform { private readonly string _beforeContent; private readonly string _afterContent; public InjectContentItemTransform(string beforeContent, string afterContent) { _beforeContent = beforeContent ?? string.Empty; _afterContent = afterContent ?? string.Empty; } public string Process(string includedVirtualPath, string input) { if (_beforeContent.Length == 0 && _afterContent.Length == 0) { return input; } var contentBuilder = new StringBuilder(); if (_beforeContent.Length > 0) { contentBuilder.AppendLine(_beforeContent); } contentBuilder.AppendLine(input); if (_afterContent.Length > 0) { contentBuilder.AppendLine(_afterContent); } return contentBuilder.ToString(); } }

そして、ファイルをバンドルに追加するときに登録します。

 using System.Web.Optimization; using BundleTransformer.Core.Bundles; using BundleTransformer.Core.Orderers; public class BundleConfig { public static void RegisterBundles(BundleCollection bundles) { var nullOrderer = new NullOrderer(); const string beforeLessCodeToInject = @"@my-variable: 'Hurrah!';"; const string afterLessCodeToInject = @"@font-family-base: 'Comic Sans MS'; @body-bg: lime; @font-size-h1: 50px;"; var commonStylesBundle = new CustomStyleBundle("~/Bundles/BootstrapStyles"); commonStylesBundle.Include( "~/Content/bootstrap/bootstrap.less", new InjectContentItemTransform(beforeLessCodeToInject, afterLessCodeToInject)); commonStylesBundle.Orderer = nullOrderer; bundles.Add(commonStylesBundle); } }

残念ながら、上記のコード例はリリースモードでのみ機能していました。これは、デバッグHTTPハンドラーがバンドル設定について何も「認識」せず、要求されたファイルのコードを単にブロードキャストするという事実によるものです。

この問題を解決するには、まず、要求されたファイルが含まれるバンドルのURLをHTTPデバッグハンドラーに渡す方法を見つける必要がありました。デコンパイラを使用してSystem.Web.Optimization.dllのアセンブリコードを調べたところ、解決策が見つかりました。独自のバージョンのBundleResolverクラスを作成し、対応するクラスに登録する必要があります。実装の詳細については説明しませんが、作成したクラスの使用方法を示します。

 … using BundleTransformer.Core.Resolvers; public class BundleConfig { public static void RegisterBundles(BundleCollection bundles) { BundleResolver.Current = new CustomBundleResolver(); … } }

その後、デバッグモードで、次のタイプのファイルへのリンクが生成されます。

 <link href="/Content/bootstrap/bootstrap.less?bundleVirtualPath=%7e%2fBundles%2fBootstrapStyles" rel="stylesheet">

クエリ文字列パラメーターbundleVirtualPathは、バンドルURLが含まれます。

そのため、バンドルURLを自由に使用できるように、カスタムエレメントトランスフォーメーションおよびバンドルレベルで指定されたトランスフォーメーション（トランスレーターとポストプロセッサー）を、ベースデバッグHTTPハンドラーの要求ファイルに適用する機能を追加しました。

さらに、2つの追加のHTTPハンドラーが作成されました。

CssAssetHandler。 CSSファイルを処理します。
JsAssetHandler。 JavaScriptファイルを処理します。

これらを使用すると、要素およびポストプロセッサのカスタム変換を静的ファイルに適用できます。要求された静的ファイルがバンドルに含まれていない場合、これらのHTTPハンドラーはSystem.Web.StaticFileHandlerクラスのインスタンスに要求を渡します。トランスレーターにバンドルされているデバッグHTTPハンドラーとは対照的に、これらのHTTPハンドラーは（NuGetパッケージのインストール中に） Web.configファイルに自動的に登録されず、手動で登録する必要があります。

 <configuration> … <system.webServer> … <handlers> … <add name="CssAssetHandler" path="*.css" verb="GET" type="BundleTransformer.Core.HttpHandlers.CssAssetHandler, BundleTransformer.Core" resourceType="File" preCondition="" /> <add name="JsAssetHandler" path="*.js" verb="GET" type="BundleTransformer.Core.HttpHandlers.JsAssetHandler, BundleTransformer.Core" resourceType="File" preCondition="" /> … </handlers> … </system.webServer> … </configuration>

Web.configファイルのファイル拡張子とリソースタイプを一致させる

以前は、ファイル拡張子をリソースタイプにマッピングすることは、 Assetコードにハードコードされていました。これで、 Web.configファイルの構成要素fileExtensionsが使用されます。

 <configuration> … <bundleTransformer xmlns="http://tempuri.org/BundleTransformer.Configuration.xsd"> <core …> <css …> … <fileExtensions> <add fileExtension=".css" assetTypeCode="Css" /> <add fileExtension=".less" assetTypeCode="Less" /> <add fileExtension=".sass" assetTypeCode="Sass" /> <add fileExtension=".scss" assetTypeCode="Scss" /> </fileExtensions> </css> <js …> … <fileExtensions> <add fileExtension=".js" assetTypeCode="JavaScript" /> <add fileExtension=".coffee" assetTypeCode="CoffeeScript" /> <add fileExtension=".litcoffee" assetTypeCode="LiterateCoffeeScript" /> <add fileExtension=".coffee.md" assetTypeCode="LiterateCoffeeScript" /> <add fileExtension=".ts" assetTypeCode="TypeScript" /> <add fileExtension=".mustache" assetTypeCode="Mustache" /> <add fileExtension=".handlebars" assetTypeCode="Handlebars" /> <add fileExtension=".hbs" assetTypeCode="Handlebars" /> </fileExtensions> </js> … </core> … </bundleTransformer> … </configuration>

上記の例は、公式のBundle Transformerモジュールがすべてインストールされている状況を示しています（ .cssおよび.js拡張子のマッピングはカーネルのインストール時に追加され、残りは対応するトランスレーターモジュールのインストール時に追加されます）。このようなアーキテクチャには、次の利点があります。

未使用のマッピングを保存する必要はありません。 原則として、実際のプロジェクトでは、すべてのタイプの翻訳者をインストールする必要はありません（たとえば、LESSとSassの同時使用は非常にまれです）。そのため、プロジェクトに保存される比較は少なくなります。
非公式の翻訳モジュールを作成する機能。 カーネルコードに依存しなくなったため、Bundle Transformerユーザーは独自のトランスレーターモジュールを作成できます。このようなモジュールの例として、 AngularBundle NuGetパッケージがあります。これは、インストールされると、次のマッピングをWeb.configファイルに追加します。
```
 <configuration> … <bundleTransformer xmlns="http://tempuri.org/BundleTransformer.Configuration.xsd"> <core> … <js …> … <fileExtensions> … <add fileExtension=".html" assetTypeCode="AngularTemplate" /> … </fileExtensions> </js> … </core> … </bundleTransformer> … </configuration> 
```

新しいファイル拡張子を既存の翻訳モジュールにバインドします。 たとえば、BundleTransformer.Hoganモジュールで拡張子が.htmlファイルの処理を開始する場合は、次のコードをWeb.configファイルに追加するだけです。

 <configuration> … <bundleTransformer xmlns="http://tempuri.org/BundleTransformer.Configuration.xsd"> <core …> … <js …> … <fileExtensions> … <add fileExtension=".html" assetTypeCode="Mustache" /> … </fileExtensions> </js> … </core> … </bundleTransformer> … <system.webServer> … <handlers> … <add name="HtmlAssetHandler" path="*.html" verb="GET" type="BundleTransformer.Hogan.HttpHandlers.HoganAssetHandler, BundleTransformer.Hogan" resourceType="File" preCondition="" /> … </handlers> … </system.webServer> … </configuration>

最小化する前にファイルコードを結合する

Bundle Transformerは、System.Web.Optimizationとは異なり、各ファイルを個別に処理します。このアプローチにはいくつかの利点があります。

さまざまなタイプのリソース（CSS、LESS、Sassファイルなど）を1つのバンドルに結合することが可能になります。
以前に最小化されたファイル（拡張子.min.cssおよび.min.jsファイル）の繰り返し最小化は.min.jsません。これにより、ほとんどの場合、バンドルへの最初のアクセス時の最小化速度が向上します。

しかし、最近のミニマイザーが提供する構造最小化機能（YandexのCSSOなど）を最大限に活用したいため、一部のBundle Transformerユーザーはこのアプローチを好まなかった。

したがって、新しいバージョンでは、 cssおよびjs構成要素にcombineFilesBeforeMinification属性（デフォルト値はfalse ）があり、最小化前にファイルコードの結合を有効にできます。

 <configuration> … <bundleTransformer xmlns="http://tempuri.org/BundleTransformer.Configuration.xsd"> <core <css … combineFilesBeforeMinification="true"> … </css> <js … combineFilesBeforeMinification="true"> … </js> … </core> … </bundleTransformer> … </configuration>

新しいモジュール

この間に、バンドルトランスフォーマー用の3つの公式モジュールが一度に作成されました。

ポストプロセッサBundleTransformer.Autoprefixer
トランスレーターBundleTransformer.Handlebars
トランスレーターBundleTransformer.Hogan

3つのモジュールはすべてJavaScriptライブラリのコードに基づいているため、インストール後すぐに、それぞれに独自のJavaScriptエンジンを選択する必要があります（詳細については、対応するNuGetパッケージのreadme.txtファイルを参照してください）。

それぞれを個別に検討してみましょう。

バンドルトランスフォーマー：自動プレフィックス

BundleTransformer.Autoprefixerモジュールには、CSSコードのベンダープレフィックスを更新するAutoprefixCssPostProcessorポストプロセッサー AutoprefixCssPostProcessorが含まれています。 AutoprefixCssPostProcessorは、一般的なCSSポストプロセッサ-Autoprefixer （バージョン3.1が現在サポートされています）に基づいています。 Andprei Sitnikの記事「Autoprefixer-CSSプレフィックス問題の最終的な解決策」からこの製品に関するすべての基本情報を強調できるため、Autoprefixerが必要な理由については説明しません。

このセクションでは、BundleTransformer.Autoprefixerを適切に構成する方法について説明します。この記事の「ポストプロセッサー」および「HTTPハンドラーの高度なデバッグ」セクションを読んでいない場合は、必ず読んでください。 BundleTransformer.Autoprefixerの操作に関連する多くの重要なポイントに触れます。

BundleTransformer.Autoprefixerをインストールし、JavaScriptエンジンを選択したら、次を実行する必要があります。

AutoprefixCssPostProcessorポストAutoprefixCssPostProcessorをアクティブなCSSポストAutoprefixCssPostProcessorのリストの最後に追加しAutoprefixCssPostProcessor 。これは、構成要素/configuration/bundleTransformer/core/cssのdefaultPostProcessors属性で設定されます。
CssAssetHandler HTTPデバッグハンドラーをWeb.configファイルにWeb.configます（デバッグモードに必要）。
CustomBundleResolverクラスのインスタンスを現在のBundleResolver `a（デバッグモードに必要）として登録します。

次に、 Web.configファイルの構成セクション/configuration/bundleTransformer/autoprefixer 、Autoprefixerアルゴリズムのオプション設定を行うことができます。

 <configuration> … <bundleTransformer xmlns="http://tempuri.org/BundleTransformer.Configuration.xsd"> … <autoprefixer cascade="true" safe="false"> <browsers> <add conditionalExpression="> 1%" /> <add conditionalExpression="last 2 versions" /> <add conditionalExpression="Firefox ESR" /> <add conditionalExpression="Opera 12.1" /> </browsers> … </autoprefixer> … </bundleTransformer> … </configuration>

autoprefixer設定セクションのすべてのプロパティを詳細に検討します。

物件	データ型	デフォルト値	説明
`browsers`	条件式リスト	`1%` `last 2 versions` 、 `Firefox ESR` 、 `Opera 12.1`	サポートされているブラウザーのサブセットを定義するための条件式のリストが含まれています。条件式の構文は、Autoprefixerの公式ドキュメントで詳細に説明されています。 `browsers`要素が指定されていないか空の場合、デフォルト値が使用されます。ベンダープレフィックスの追加を完全に無効にするには、 `none`等しい1つの条件式のみを`browsers`要素に残す必要があります。
`cascade`	ブール値	`true`	次の形式のプレフィックスの視覚的なカスケードを作成します。 `-webkit-box-sizing: border-box; -moz-box-sizing: border-box; box-sizing: border-box;`
`safe`	ブール値	`false`	壊れたCSSコードを解析するための特別なセーフモードを有効にします。

バンドルトランスフォーマー：ハンドルバー

BundleTransformer.Handlebarsモジュールには、JavaScriptでHandlebarsテンプレートをプリコンパイルするHandlebarsTranslator トランスレーターアダプターが含まれています。 HandlebarsTranslatorは、一般的なテンプレートエンジン-Handlebars.js （バージョン2.0.0が現在サポートされています）に基づいています。このトランスレータはテンプレートエンジンに基づいているという事実にもかかわらず、JavaScriptコードを生成する他のトランスレータと大差ありません。テンプレートコードを持つファイル（デフォルトでは、トランスレータは拡張子.handlebarsおよび.hbs持つファイルを処理します）は、スクリプトバンドルに登録する必要があります。

 … using Core.Bundles; using Core.Orderers; … public class BundleConfig { public static void RegisterBundles(BundleCollection bundles) { … var commonTemplatesBundle = new CustomScriptBundle("~/Bundles/CommonTemplates"); commonTemplatesBundle.Include( … "~/Scripts/handlebars/handlebars.runtime.js", "~/Scripts/handlebars/HandlebarsHelpers.js", "~/Scripts/handlebars/HandlebarsTranslatorBadge.handlebars", …); commonTemplatesBundle.Orderer = nullOrderer; bundles.Add(commonTemplatesBundle); … } }

CoffeeScriptやTypeScriptとは異なり、コンパイル済みのHandlebarsテンプレートには、 handlebars.runtime.jsファイル（テンプレートのコンパイルに必要なコードが除外されたhandlebars.jsライブラリのhandlebars.jsバージョン）が必要です。このファイルは、共有ライブラリのバンドルまたはHandlebarsテンプレートのバンドルに配置できます。主なものは、彼の広告がテンプレートの発表前に行くことです。

Web.configファイルの構成セクション/configuration/bundleTransformer/handlebarsで、テンプレートのプリコンパイルを構成できます。

 <configuration> … <bundleTransformer xmlns="http://tempuri.org/BundleTransformer.Configuration.xsd"> … <handlebars namespace="Handlebars.templates" rootPath="" knownHelpers="link" knownHelpersOnly="true" data="false"> … </handlebars> … </bundleTransformer> … </configuration>

handlebars構成セクションのすべてのプロパティを詳細に検討します。

物件	データ型	デフォルト値	説明
`namespace`	ひも	`Handlebars.templates`	テンプレートの名前空間を指定します。
`rootPath`	ひも	空行	テンプレートのルートディレクトリへのパスを指定します。次のテンプレートURLがあるとします- `/Scripts/handlebars/discussions/index.hbs` 。デフォルトでは、そのようなテンプレートの名前はファイル名- `index`から抽出されますが、このプロパティを`/Scripts/handlebars/`に設定すると、次のテンプレート名- `discussions/index`取得され`discussions/index` 。
`knownHelpers`	ひも	空行	既知のヘルパーのコンマ区切りリストが含まれます。このリストにヘルパー名を追加すると、それらへの呼び出しを最適化できるため、コンパイルされたテンプレートのサイズが小さくなります。
`knownHelpersOnly`	ブール値	`false`	既知のヘルパーのみの使用を許可します。このプロパティの値が`true`で、テンプレートコードに組み込みでないヘルパーまたは`knownHelpers`プロパティで宣言されていないヘルパーへの呼び出しが含まれている場合、例外がスローされます。
`data`	ブール値	`true`	コンパイルでテンプレート内の@データ変数のデータを含めることができます（例： `@index` ）。テンプレートに反復ブロックがあり、@ data変数が使用されていない場合、このプロパティを`false`に設定することをお勧めし`false` -これによりパフォーマンスが向上します。

また、テンプレートコードを含むファイルの名前がアンダースコアで始まる場合、テンプレートはグローバルな部分表現としてコンパイルされます（最初のアンダースコアはテンプレート名から削除されます）。

バンドルトランス：ホーガン

BundleTransformer.Hoganモジュールには、JavaScriptでMustacheテンプレートをプリHoganTranslatorするHoganTranslatorが含まれています。 HoganTranslatorは、人気のあるMustacheテンプレートコンパイラであるHogan.js （現在、バージョン3.0.2がサポートされています）に基づいています。 BundleTransformer.Hoganの動作原理は、多くの点でBundleTransformer.Handlebarsの動作原理に似ているため、重要な違いのみを考慮します。 ( .mustache ) :

 … using Core.Bundles; using Core.Orderers; … public class BundleConfig { public static void RegisterBundles(BundleCollection bundles) { … var commonTemplatesBundle = new CustomScriptBundle("~/Bundles/CommonTemplates"); commonTemplatesBundle.Include( "~/Scripts/hogan/template-{version}.js", "~/Scripts/hogan/HoganTranslatorBadge.mustache", …); commonTemplatesBundle.Orderer = nullOrderer; bundles.Add(commonTemplatesBundle); … } }

Handlebars JavaScript- — template-3.0.2.js ( , , ).

/configuration/bundleTransformer/hogan Web.config :

 <configuration> … <bundleTransformer xmlns="http://tempuri.org/BundleTransformer.Configuration.xsd"> … <hogan useNativeMinification="false" variable="templates" namespace="" delimiters=""> <sectionTags> <add sectionName="newWindow" openingTagName="_newWindow" closingTagName="newWindow" /> </sectionTags> … </hogan> … </bundleTransformer> … </configuration>

hogan :

			説明
`useNativeMinification`		`false`	`true` , , .
`variable`	ひも	`templates`	JavaScript-, .
`namespace`	ひも		, .
`sectionTags`			, . , `_newWindow` `newWindow` , `{{_newWindow}} target="_blank"{{/newWindow}}` .
`delimiters`	ひも		, . , ASP, – `<% %>` ( `Web.config` — `<% %>` ).

Bundle Transformer：Summer Update