Jak rozpoznać elementy <xsl:import> i <xsl:include> ze względnymi ścieżkami podczas korzystania z xsltc.exe XslCompiledTransforms?

Question

W ramach procesu kompilacji aplikacji internetowej skonfigurowałem arkusze stylów XSLT, które zostaną zbudowane przy użyciu kompilatora Microsoft's xsltc.exe, gdy uruchomimy pełną kompilację. Podczas lokalnego rozwoju działało to świetnie, ponieważ kod jest kompilowany i hostowany w tej samej lokalizacji. Jednak po umieszczeniu tego na serwerze kompilacji pojawiły się problemy.

Serwer build będzie kompilacji stylów XSLT jak zrobić lokalnie, ale następnie uruchamia skrypt, który instaluje skompilowany kod do naszego wewnętrznego serwera testowego internetowej. Po przeniesieniu tych plików binarnych z miejsca, w którym zostały skompilowane, względne ścieżki w elementach <xsl:import> i <xsl:include> nie są już poprawnie rozwiązywane, powodując wyjątki, które wyglądają tak, gdy są uruchamiane arkusze stylów 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) 

Oto ogólny pomysł kodu, gdyż stoi teraz:

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

Teraz używam metody XslCompiledTransform.Load() za pomocą jednego parametru „typ”, aby doprowadzić w oparte na xsltc.exe wstępnie skompilowane arkusze stylów XSLT. Mogę powiedzieć ze śledzenia stosu, że platforma .NET używa XmlUrlResolver, aby spróbować rozwiązać faktyczną lokalizację tych zewnętrznych arkuszy stylów, ale nie widzę sposobu na nadpisanie implementacji XmlResolver, w którym mógłbym przekazać nowy baseUri wskazujące, gdzie te arkusze stylów znajdują się na serwerze sieciowym.

Zakładam mogę rozwiązać ten problem nie jest już pre-kompilacji z xsltc.exe i załadowaniem arkuszy stylów XSLT poprzez XmlReaders, ponieważ pozwoli mi korzystać z other XslCompiledTransform.Load() methods które mają parametr, gdzie mogę zapewnić własną implementację XmlResolver. Jednak podoba mi się opcja wstępnej kompilacji do sprawdzania składni i wydajności, więc nie chcę rezygnować, chyba że absolutnie muszę.

Czy istnieje sposób na wykorzystanie xsltc.exe wstępnie skompilować te arkusze stylów XSLT, a jednocześnie zapewnić sposób wyraźne określenie baseUri dla rozdzielczości względnej ścieżki z <xsl:include> i <xsl:import> elementów w czasie wykonywania?

Answer 1

Po dużo grania na około w ten sposób dowiedziałem się, że miałem rację, że podany przeze mnie kod automatycznie używa System.Xml.XmlUrlResolver do rozstrzygania względnych ścieżek w czasie wykonywania. Jednak użycie XmlUrlResolver nie jest związane z System.Xml.XslCompiledTransform, gdy jest umieszczone w plikach binarnych przez xsltc.exe. XmlResolver jest faktycznie wybrany przez właściwość XmlResolver na System.Xml.XmlReaderSettings na System.Xml.XmlReader, która wykonuje transformację w czasie wykonywania. Po ustawieniu własnego niestandardowego XmlResolver na XsltReaderSettings, którego używałem, byłem w stanie kontrolować względną rozdzielczość ścieżki.

Jeśli chcesz zmienić to XmlResolver jak ja, następujący kod może być użyty jako przewodnik:

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); 
    } 
} 

nadal używam xsltc.exe skompilować moje arkuszy stylów XSLT, ale kiedy załadować te skompilowane stylów na serwerze WWW wtrysku SomeCustomXmlResolver przepisuje ścieżki w nadpisanych metodach ResolveUri() i GetEntity(), dzięki czemu można znaleźć pliki odniesienia, które znajdują się w ścieżkach względnych opartych na <xsl:include> i <xsl:import>. Dodatkową korzyścią jest to, że dodając ten sam XmlResolver na końcu metody Transform(), operacje w kodzie XML również będą miały poprawne ścieżki względne.

Answer 2

Nie wiem, czy to łamie swój system, ale jak o zamiast

1. kompilacji z xsltc.exe
2. wdrażania binarne
3. załadowanie binarnie z this Load()

ty

1. wdrożyć arkusze stylów, jednak wiele z nich jest wymagana z dyrektywami import/include
2. obciążenie głównym arkusza stylów z this Load(), określając rozpoznawania nazw dla import/incldue

Okazuje się nadal będziesz uzyskać korzyść „skompilowany” arkusz stylów, przynajmniej w czasie wykonywania.

Answer 3

Czy istnieje sposób użycia xsltc.exe do wstępnej kompilacji arkuszy stylów XSLT, , ale nadal zapewnia sposób jawnego określenia baseUri dla względnej rozdzielczości ścieżki <xsl:include> i <xsl:import> w środowisku wykonawczym?

spróbuje użyć:

XslCompiledTransform.CompileToType()

Jednym z argumentów, że ta metoda statyczna akceptuje to:

XmlResolver stylesheetResolver