Ausnahme "stylesheet ist zu Komplex" beim laden von großen XSLT-in .NET 4.5

Bin ich immer eine Ausnahme beim laden eines XSLT-stylesheet. Das XSLT-stylesheet ist sehr groß (fast 8000 Zeilen). Leider weiß ich nicht, haben keine Kontrolle über diese, und ich bin nicht in der Lage umgestalten das stylesheet, um es zu verkleinern.

Wir haben vor kurzem aktualisiert .Net Framework 4.5. Das folgende Kommando funktioniert nur vor dem upgrade (wir waren mit .Net Framework 4.0). Nach der Aktualisierung erhalten wir eine XsltException sagt man: "Das stylesheet ist zu Komplex" auf dietransform.Load Linie.

Ich hatte gehofft, dass es irgendeine neue Einstellung, die sagen würde "Stellen Sie mit diesem Befehl arbeiten, wie es in 4.0", aber ich konnte nichts finden, nirgendwo.

Weiß jemand, der einige Grund, warum dieses könnte plötzlich ein problem in der version 4.5? Wie kann es gelöst werden?

XslCompiledTransform transform = new XslCompiledTransform();
transform.Load(XmlReader.Create(report), new XsltSettings { EnableScript = true }, new XmlUrlResolver());

report ist ein MemoryStream-enthält die großen XSLT-stylesheet.

Bitte keine tags verwenden, die in Ihrer Frage-Titel
Liest sich jetzt viel besser. Vielen Dank für den edit.
Bitte do verwenden, Thema, Schlüsselwörter in deiner Frage-Titel, wenn Sie wichtig sind für die Klärung des Themas (auch wenn Sie sich zufällig auch für tags). Die einzige Antwort auf die Frage @Ryan verknüpft empfiehlt Thema Schlagworte (auch tags) in einem Titel wie "Kann ich mit jQuery verwenden, um ..." Die word-stylesheet ist mehrdeutig genug, dass das qualifying mit XSLT in den Titel lohnt.
Ja @RyanGates, während der ursprüngliche Titel war lang, es klar gesagt das Problem, während der neue Titel, den Sie Gaben, es war viel mehr zweideutig: Welche Art von stylesheet (CSS -?); Welche Plattform (FireFox?, Java?). Ein Mehrdeutiger Titel zwingt die Menschen zu unnötig die Frage offen, um herauszufinden, was es ist.
Ich bin hier falsch. Ich persönlich glaube nicht, dass der Titel mehrdeutig ist, wenn man sich die tags. Das sagte nach der Lektüre der link-mehr eng ich sehen kann, was du meinst, über die Unterscheidung zwischen organischen und gezwungen.
Gen S., ich glaube, man muss dankbar sein für diese Fehlermeldung bekommen. 8000 Zeilen code würde in etwa passen auf 134 Seiten -- wer würde schon wollen, zugewiesen werden, dies aufrecht zu erhalten? Vor 10 Jahren fand ich ein 29-Seite C# - Methode in mein client-code-und war fassungslos, -- jetzt dieser schlägt alle Rekorde.
Ich war in der Lage das Problem zu reproduzieren. Es geht auch nicht mit der alten XslTransform entweder. Es scheint zu gehen in eine rekursive Methode at System.Xml.Xsl.Qil.QilDepthChecker.Check(QilNode input, Int32 depth) wo es stirbt. Ich konnte nicht herausfinden, wie man die Quelle für das für alle Hinweise entweder.
Das stylesheet dynamisch generiert werden, basierend auf Benutzereingaben. Die meisten der Zeit, die das erzeugte stylesheet ist klein, in sehr seltenen Fällen, wird es sehr groß. Das stylesheet Leben nur im Gedächtnis, wenn der Prozess läuft, so gibt es keine Wartung.
8000 Zeilen, klingt nicht sehr groß für mich - etwa die gleiche wie die stylesheets verwenden wir für die Erzeugung des W3C-Spezifikationen. docbook ist sicherlich ist ganz ein bisschen größer. Sie könnten immer versuchen, ein anderes XSLT-Prozessor...
Hallo, ich bin aus .NET Framework-Kompatibilität-team. Wir möchten, um diese besser zu verstehen. Können Sie mit uns Kontakt auf netfx45compat bei Microsoft dot com mit klein-Projekt, das Problem zu reproduzieren?
E-Mail wurde gesendet.

InformationsquelleAutor Gene S | 2013-04-18

.net-4.5 c#xslt

10

Stellt sich heraus, das ist eine Funktion/defekt in der .Net Framework 4.5. Nachricht von Microsoft...

Vor kurzem haben wir ein Update für dieses in einem hotfix-rollup. Sehen http://support.microsoft.com/kb/2828843 für .NET Framework 4.0 und http://support.microsoft.com/kb/2828841 für .NET Framework 4.5.

Dann füge dies in deine config-Datei und das problem sollte Weg gehen.
```
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <configSections>
    <sectionGroup name="system.xml">
      <section name="xslt" type="System.Xml.XmlConfiguration.XsltConfigSection, System.Xml, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false"/>
    </sectionGroup>
  </configSections>
  <system.xml>
    <xslt limitXPathComplexity="false"/>
  </system.xml>
  <startup>
    <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5"/>
  </startup>
</configuration>
```
Dies ist mein problem gelöst.
- Das ist richtig. Aus irgendeinem Grund Microsoft erfordert, dass Sie nehmen Sie Kontakt auf, Holen Sie sich den Hotfix. Aber es ist ein link auf jeder der KB-Seiten, bietet eine Möglichkeit zur Kontaktaufnahme mit Microsoft.
- Ich weiß nicht, wie diese, ich mag es nicht, ein bit. Mit der Zeit bekomme ich das, was ich von Ihnen will, habe ich ausgetestet, den harten Weg (ich habe eigentlich nur getan, dass...)
- Interessant, wenn ich Sie kontaktiert, ich habe den hotfix am selben Tag.
- Ich habe nie behauptet, er habe versucht, Sie zu Kontaktieren. Das ist sowieso nicht wichtig. Die KB könnte schon eher auf den Punkt, mindestens. Ein download-link würde wurden ausgezeichnet.
- Eigentlich ist diese nur verschiebt sich das Problem von Parsen/Kompilieren die XSLT-Ausführung. Es scheint, dass dies ist ein Sicherheits-Feature gegen Stack Overflows, die MS eingebaut. Deaktivieren Sie führte zu Stack-Overflows mit unseren 3000 Zeichen XSLT. Wie Sie wissen SOs kann nicht gefangen werden und wird den Prozess zu beenden, so ist dies ziemlich riskant! Wir haben umgestaltet werden, die XSLT durch die Einführung von Variablen für Häufig verwendete Node-Sets, aber letztendlich hatte zu Beginn eine benutzerdefinierte Worker-Thread-Pool mit einer erhöhten Stack-Größe zu behandeln, die XSLTs.
InformationsquelleAutor Gene S
2

Ich hatte das gleiche Problem, und isoliert es zu einem Maschine-generierten choice-element mit mehr als 1500 xsl:when-Elemente. Weitere Tests bewiesen .NETTO-4.7 geben wird, die "zu Komplex" Ausnahme bei 789 wenn-Elemente oder mehr.

Einstellung limitXPathComplexity auf false, app.config stürzt das Programm mit einer StackOverflowException statt.

Den gleichen code auf .NET Core 2.0 wirft StackOverflowException bei ca 2800-Elemente. Ich habe den bug gemeldet hat, um beide Mannschaften, aber nicht erwarten, dass es priorisiert werden jederzeit schnell.
- Es scheint, dass dies ist ein Sicherheits-Feature gegen Stack Overflows, die MS eingebaut. Wir haben umgestaltet werden, die XSLT durch die Einführung von Variablen für Häufig verwendete Node-Sets, aber letztendlich hatte zu Beginn eine benutzerdefinierte Worker-Thread-Pool mit einer erhöhten Stack-Größe von 2MB zu handhaben, die XSLTs esp. auf dem IIS-wo-Stack-Größe ist nur mit 256/512kB für 32/64Bit-Prozesse. Das funktioniert so weit.
InformationsquelleAutor EventHorizon
0

Ich arbeitete um dieses Problem durch ersetzen Tausende von xsl:choose und xsl:if-Anweisungen verwendet für Schlüssel/Werte-mapping mit einer externen xml-Datei-Schlüssel/Wert-lookup.

Plagiarised Methode hier - credits unten.

In Bezug auf die XSLT-der beste Weg ist, um das lookup-Daten als ein XML-Dokument, Sie könnten dann laden Sie mit dem XSLT-Dokument-Funktion. Zum Beispiel, wenn Sie Ihre lookup-XML in form von z.B.
```
<list>
  <data key="k1" value="value 1"/>
  <data key="k2" value="value 2"/>
  <data key="k3" value="value 3"/>
</list>
```
dann mit XSLT können Sie z.B.
```
<xsl:variable name="data" select="document('lookup.xml')/list/data"/>

<xsl:for-each select="foo">
  <xsl:value-of select="$data[@key = current()]/@value"/>
</xsl:for-each>
```
Keine Notwendigkeit, xsl:choose. Natürlich ist die Dokument-Funktion nicht haben, laden Sie eine statische Datei ist, könnte es eine GET-Anforderung an einen HTTP-server, dient die XML-Datei.

credits:
https://social.msdn.microsoft.com/Forums/en-US/9b5966a1-aa1e-46db-88f8-3f4a9aeadb5b/best-way-to-handle-a-lookup-in-xslt-data-is-already-in-a-database?forum=xmlandnetfx

http://etutorials.org/XML/xml+hacks/Chapter+3.+Transforming+XML+Documents/Hack+56+Use+Lookup+Tables+with+XSLT+to+Translate+FIPS+Codes/

InformationsquelleAutor TimDude

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.