En utilisant un ensemble de scripts dans un modèle de référence XSL

Question

Il y a deux fichiers XSL. Un autre comprend l'utilisation d'un <xsl:include>. Le modèle principal décide quels modèles réels d'appeler en fonction des valeurs de nœud et inclus des modèles contiennent des règles de transformation réelle. Rien de spécial ici.

Mais fichier inclus a un bloc de script:

  <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>

L'utilisateur:. Fonction escape () est utilisée plus tard dans le modèle inclus

Maintenant, je vais débogueur XSLT VS2008.

Le modèle principal appelle <xsl:apply-templates> et le modèle inclus exécute. Et une exception FileNotFound se produit, "Impossible de charger le fichier ou l'assembly 'MyEscaper, Version = 1.0.0.0, Culture = neutral, PublicKeyToken = null' ou une de ses dépendances. Le système ne peut pas trouver le fichier spécifié."

Maintenant, si je vais juste le fichier inclus et l'exécuter comme si elle était un modèle autonome, non inclus dans quoi que ce soit, tout fonctionne. L'assemblage se trouve et la fonction est appelée, mais évidemment les résultats ne font pas de sens que le modèle conçu pour être une inclusion.

La question - pourquoi ne pas le système peut trouver l'ensemble lorsque le modèle est inclus

Plus d'informations

Documentation stipule que « Le nom de chemin d'assemblage est résolu deux fois - une fois lors de la compilation et une fois lors de l'exécution. » Si je fais intentionnellement une faute de frappe dans le chemin, je reçois même exception FileNotFound, formatées différemment, où le système dit qu'il ne peut pas trouver le fichier : // C: \ absolu \ Path \ MyEscaper.dll . Toutefois, lorsque le chemin est correct, l'exception prétend qu'il n'a pas pu trouver MyEscaper.dll, version = blabla, jeton publique = null , et cette exception se produit dans CompiledStylesheet.dll créé par .Net. Je crois que la feuille de style compilé est dit d'appeler l'assemblée par son nom, et non par href, et comme il est pas dans son dossier temporaire, l'appel échoue.

Pourquoi? Où et pourquoi un chemin absolu se traduit (à tort) dans un rapport, et comment puis-je contrôler?

Answer 1

.

Pour une raison quelconque, dans un chemin de scénario inclus à l'assemblée est résolu différemment lors de la compilation et lors de l'exécution. Pourquoi est-il, je ne l'ai pas la moindre idée.

Seules deux solutions saines ont été trouvées:

1. Déplacer tout le code de l'ensemble référencé dans le modèle XSL, ce qui en fait un script intégré. En cas de petites fonctions d'assistance qui est en fait préféré. Dans le cas contraire,

2. Inscrivez-vous l'assembly référencé avec un nom fort, ajoutez au GAC, et y référer à des modèles utilisant name, non href. De cette façon, l'ensemble sera regardé de la même manière lors de la compilation et de l'exécution, et se trouve.