Utilisation d'un assemblage pour la création de scripts dans un modèle XSL référencé

Question

Il existe deux fichiers XSL. L'un en inclut un autre en utilisant un <xsl:include>. Le modèle principal décide quels modèles réels appeler en fonction des valeurs de noeud, et les modèles inclus contiennent des règles de transformation réelles. 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: la fonction escape() est utilisée plus tard dans le modèle inclus.

Maintenant, je vais au débogueur VS2008 XSLT.

Le modèle principal appelle <xsl:apply-templates> et le modèle inclus s'exécute. Et une exception FileNotFound se produit, "Impossible de charger le fichier ou l'assembly 'MyEscaper, Version = 1.0.0.0, Culture = neutre, PublicKeyToken = null' ou l'une de ses dépendances.Le système ne peut pas trouver le fichier spécifié." Maintenant, si je vais juste au fichier inclus et l'exécute comme s'il s'agissait d'un modèle autonome, non inclus dans quoi que ce soit, tout fonctionne. L'assemblage est trouvé et la fonction est appelée, mais évidemment les résultats n'ont pas de sens comme le modèle conçu pour être une inclusion. Donc, la question - pourquoi le système ne peut-il pas trouver l'assemblage lorsque le modèle est inclus?

Plus d'informations

documentation indique 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, j'obtiens la même exception FileNotFound, mais formatée différemment, où le système indique qu'il ne peut pas trouver file: // C: \ Absolute \ Path \ MyEscaper.dll. Toutefois, lorsque le chemin d'accès est correct, l'exception prétend qu'il n'a pas pu trouver MyEscaper.dll, version = blabla, jeton public = 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'assembly par nom, pas par href, et puisque ce n'est pas dans son dossier temporaire, l'appel échoue.

Pourquoi cela? Où et pourquoi un chemin absolu est-il traduit (à tort) en un chemin relatif, et comment puis-je le contrôler?

Answer 1

Donc.

Pour une raison quelconque, dans un scénario inclus, le chemin d'accès à l'assemblage est résolu différemment pendant la compilation et pendant l'exécution. Pourquoi c'est ainsi, je n'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é. Dans le cas de fonctions d'aide de petite taille qui est réellement préféré. Sinon,

2. Signez l'assembly référencé avec un nom fort, ajoutez-le au GAC et faites-en référence à partir de modèles en utilisant name, et non href. De cette façon, l'assemblage sera recherché de la même manière lors de la compilation et de l'exécution, et sera trouvé. Etes-vous en train d'exécuter le code xslt à partir du code C#/vb?