3

2つのXSLファイルがあります。1つには、を使用した別のが含まれます<xsl:include>。メインテンプレートは、ノード値に応じて呼び出す実際のテンプレートを決定し、含まれているテンプレートには実際の変換ルールが含まれています。ここでは特別なことは何もありません。

ただし、含まれているファイルにはスクリプトブロックがあります。

  <msxsl:script language="VB" implements-prefix="user">
    <msxsl:assembly href="C:\Absolute\Path\MyEscaper.dll" />
    <msxsl:using namespace="ZebraEscaper.MyCompany" />
    <![CDATA[
    Public Function escape(s As String) As String
      Return EncodeField(s, True)
    End Function
    ]]>
  </msxsl:script>

user：escape（）関数は、後で含まれているテンプレートで使用されます。

次に、VS2008XSLTデバッガーに移動します。

メインテンプレートが呼び出さ<xsl:apply-templates>れ、含まれているテンプレートが実行されます。また、FileNotFound例外が発生し、「ファイルまたはアセンブリ'MyEscaper、Version = 1.0.0.0、Culture = neutral、PublicKeyToken=null'またはその依存関係の1つを読み込めませんでした。システムは指定されたファイルを見つけることができません。」

ここで、含まれているファイルだけに移動して、何にも含まれていないスタンドアロンテンプレートであるかのように実行すると、すべてが機能します。アセンブリが検出され、関数が呼び出されますが、インクルージョンとして設計されたテンプレートとして、結果は明らかに意味がありません。

では、質問-テンプレートが含まれているのに、なぜシステムがアセンブリを見つけられないのでしょうか？

詳しくは

ドキュメントには、「アセンブリパス名は2回解決されます。1回はコンパイル中、もう1回は実行中です」と記載されています。パスに意図的にタイプミスをすると、同じFileNotFound例外が発生しますが、フォーマットが異なり、システムはfile：// C：\ Absolute \ Path\MyEscaper.dllを見つけることができないと言います。ただし、パスが正しい場合、例外はMyEscaper.dll、version = blabla、public token = nullが見つからなかったと主張し、その例外は.Netによって作成されたCompiledStylesheet.dllで発生します。コンパイルされたスタイルシートは、hrefではなく名前でアセンブリを呼び出すように指示されていると思います。また、一時フォルダーにないため、呼び出しは失敗します。

なぜそうなのか？絶対パスが（誤って）相対パスに変換される場所と理由、およびそれを制御するにはどうすればよいですか？

4

1 に答える 1

3

それで。

何らかの理由で、含まれているシナリオでは、アセンブリへのパスは、コンパイル中と実行中に異なる方法で解決されます。なぜそうなのか、私には手がかりがありません。

2つの正しい解決策だけが見つかりました：

  1. 参照されているアセンブリからすべてのコードをXSLテンプレートに移動して、埋め込みスクリプトにします。実際に好まれる小さなヘルパー関数の場合。さもないと、

  2. 参照されるアセンブリに厳密な名前で署名し、GACに追加して、テンプレートからでnameはなく、を使用して参照しhrefます。このようにして、アセンブリはコンパイルおよび実行中に同じ方法で検索され、検出されます。

于 2010-01-21T12:20:03.043 に答える