Использование сборки для сценариев в указанном шаблоне XSL - PullRequest
Новая
       11

Использование сборки для сценариев в указанном шаблоне XSL

3 голосов
/ 15 января 2010

Есть два XSL-файла. Один включает другой, используя <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 () позже используется во включенном шаблоне.

Теперь я перехожу к отладчику VS2008 XSLT.

Основной шаблон вызывает <xsl:apply-templates>, и включенный шаблон выполняется. И возникает исключение FileNotFound: «Не удалось загрузить файл или сборку» MyEscaper, Version = 1.0.0.0, Culture = нейтральный, PublicKeyToken = null 'или одна из его зависимостей. Система не может найти указанный файл. "

Теперь, если я перейду только к включенному файлу и выполню его, как если бы это был автономный шаблон, ни во что не включенный, все работает. Сборка обнаруживается и вызывается функция, но результаты, очевидно, не имеют смысла, поскольку шаблон предназначен для включения.

Итак, вопрос - почему система не может найти сборку при включенном шаблоне?

Дополнительная информация

В документации говорится, что «имя пути сборки разрешается дважды - один раз во время компиляции и один раз во время выполнения». Если я намеренно сделаю опечатку в пути, я получу то же исключение FileNotFound, но отформатированный по-другому, где система говорит, что не может найти файл : // C: \ Absolute \ Path \ MyEscaper.dll . Однако, когда путь указан правильно, исключение утверждает, что не удалось найти MyEscaper.dll, version = blabla, public token = null , и это исключение возникает в CompiledStylesheet.dll, созданной .Net. Я считаю, что скомпилированная таблица стилей должна вызывать сборку по имени, а не по href, и, поскольку она не находится во временной папке, вызов не выполняется.

Почему так? Где и почему абсолютный путь переводится (ошибочно) в относительный, и как мне его контролировать?

1 Ответ

3 голосов
/ 21 января 2010

Зв

По какой-то причине во включенном сценарии путь к сборке разрешается по-разному во время компиляции и во время выполнения. Почему это так, я понятия не имею.

Было найдено только два вменяемых решения:

  1. Переместите весь код из указанной сборки в шаблон XSL, сделав его встроенным скриптом. В случае небольших вспомогательных функций это на самом деле предпочтительнее. В противном случае,

  2. Подпишите ссылочную сборку строгим именем, добавьте ее в GAC и обратитесь к ней из шаблонов, используя name, а не href. Таким образом, сборка будет найдена таким же образом во время компиляции и выполнения, и будет найдена.

...