¿Cómo puedo resolver los elementos <xsl:import> y <xsl:include> con rutas relativas al usar xsltc.exe XslCompiledTransforms?

Question

Como parte del proceso de compilación de nuestra aplicación web, configuré nuestras hojas de estilo XSLT para compilar con el compilador Microsoft's xsltc.exe cada vez que ejecutamos una compilación completa. Durante el desarrollo local, esto funcionó muy bien, ya que el código se compila y aloja en la misma ubicación. Sin embargo, una vez que esto se puso en el servidor de compilación, surgieron problemas.

El servidor de compilación compilará las hojas de estilos XSLT tal como lo hago localmente, pero luego se ejecuta una secuencia de comandos que despliega el código compilado en nuestro servidor web de ensayo interno. Una vez que estos archivos binarios se han movido desde donde se compilaron, las rutas relativas en los elementos <xsl:import> y <xsl:include> ya no se resuelven correctamente, lo que provoca excepciones que se ven así cuando se ejecutan las hojas de estilo XSLT.

Could not find a part of the path 'e:\{PATH}\xslt\docbook\VERSION'. 
    at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath) 
    at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy, Boolean useLongPath) 
    at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options, String msgPath, Boolean bFromProxy) 
    at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize) 
    at System.Xml.XmlUrlResolver.GetEntity(Uri absoluteUri, String role, Type ofObjectToReturn) 
    at System.Xml.Xsl.Runtime.XmlQueryContext.GetDataSource(String uriRelative, String uriBase) 

Aquí es una idea general del código tal como está ahora:

var xslt = new XslCompiledTransform(); 
xslt.Load(typeof(Namespace.XslTransforms.CompiledXsltStylesheet)); 
xslt.Transform("input.xml", "output.xml"); 

En este momento estoy usando el método XslCompiledTransform.Load() con un único parámetro 'Tipo' para que en el xsltc.exe-based pre-compiled XSLT stylesheets. Puedo deducir por el seguimiento de la pila que .NET Framework está usando XmlUrlResolver para tratar de resolver la ubicación real de estas hojas de estilo externas, pero no veo una manera de proporcionar una implementación anulada de XmlResolver donde podría pasar una nueva baseUri que apunta a dónde viven estas hojas de estilo en el servidor web.

Supongo que puedo resolver esto ya no compilando previamente con xsltc.exe y cargando las hojas de estilo XSLT a través de XmlReaders, ya que eso me permitirá usar el other XslCompiledTransform.Load() methods que tiene un parámetro donde podría proporcionar mi propia implementación de XmlResolver. Sin embargo, me gusta la opción de compilación previa para la validación de la sintaxis y el rendimiento, por lo que no quiero renunciar a ella a menos que sea absolutamente necesario.

¿Hay una manera de utilizar xsltc.exe comprobar la validez de recopilar estas hojas de estilo XSLT, y aún así proporcionar una manera de indicar explícitamente el baseURI para la resolución de la ruta relativa <xsl:include> y <xsl:import> elementos en tiempo de ejecución?

Answer 1

Después de un mucho de jugar alrededor con esto, descubrí que tenía razón en que el código que proporcioné automáticamente usa el System.Xml.XmlUrlResolver para resolver las rutas relativas <xsl:include> y <xsl:import> en tiempo de ejecución. Sin embargo, el uso de XmlUrlResolver no está vinculado al System.Xml.XslCompiledTransform cuando se coloca en un archivo binario por xsltc.exe. El XmlResolver es realmente elegido por la propiedad XmlResolver en el System.Xml.XmlReaderSettings en el System.Xml.XmlReader que realiza la transformación en tiempo de ejecución. Una vez que configuré mi propio XmlResolver personalizado en XsltReaderSettings que estaba usando, pude controlar la resolución relativa de la ruta.

Si desea anular esta XmlResolver como lo hice, el código siguiente se puede utilizar como guía:

var customXmlResolver = new SomeCustomXmlResolver(); // Derives from XmlResolver 
var xmlReaderSettings = new XmlReaderSettings { 
    XmlResolver = customXmlResolver 
}; 

var xslt = new XslCompiledTransform(); 
xslt.Load(typeof(Namespace.XslTransforms.CompiledXsltStylesheet)); 

using (var xmlReader = XmlReader.Create("input.xml", xmlReaderSettings)) { 
    using (var xmlWriter = XmlWriter.Create("output.xml")) { 
    xslt.Transform(xmlReader, null, xmlWriter, customXmlResolver); 
    } 
} 

Sigo usando xsltc.exe para compilar mis hojas de estilo XSLT, pero cuando cargo estas hojas de estilo compiladas en el servidor web, el SomeCustomXmlResolver inyectado reescribe las rutas en los métodos ResolveUri() y GetEntity() reemplazados para que puedan encontrarse los archivos referenciados que viven en las rutas relativas basadas en <xsl:include> y <xsl:import>. Como una ventaja adicional, al agregar el mismo XmlResolver al final del método Transform(), las operaciones en el XML también tendrán sus rutas relativas resueltas correctamente.

Answer 2

No sé si esto se rompe el sistema, pero que tal vez de

1. compilar con xsltc.exe
2. desplegar el binario
3. cargar el binario con this Load()

usted

1. desplegar las hojas de estilo, sin embargo, muchos están obligados con las directivas import/include
2. carga de la hoja de estilo principal, con this Load(), especificando el sistema de resolución para la import/incldue

Parece que todavía obtendrá el beneficio de un "compilado" hoja de estilo, al menos en tiempo de ejecución.

Answer 3

¿Hay alguna manera de usar xsltc.exe para precompilar estas hojas de estilo XSLT, y aún así proporcionar una forma de declarar explícitamente la baseUri para la resolución relativa de ruta de <xsl:include> y <xsl:import> elementos en tiempo de ejecución?

Intente utilizar:

XslCompiledTransform.CompileToType()

Uno de los argumentos que este método estático acepta es:

XmlResolver stylesheetResolver