Wir haben festgestellt, dass eine unserer automatisch generierten Assemblys eine StackOverflowException auf new () auslöst. Diese Klasse verfügt über mehr als 400 einfache Eigenschaften, die in einem Konstruktor initialisiert werden (die meisten standardmäßig (Zeichenfolge) usw.).

Wir bemerken, dass es auf 64 Bit in Ordnung ist, aber auf 32 Bit geht es schief!

Wir müssen testen, ob es für unseren Anwendungsfall sinnvoll ist, einen größeren Standardstapel zu erstellen, um uns Luft zu verschaffen, während wir den Codegenerator neu entwickeln.

Wir würden esp. interessiert an Lösungen, die app.config betreffen, wenn möglich. Aber ich bin ein Realist, also wäre alles gut.

Zu den Gründen für den Stapelüberlauf. Wir haben den Fehler im fraglichen Konstruktor eingegrenzt. Mein erster Eindruck war auch von der Art der unendlichen Rekursion. Wir haben den Fehler jedoch mit einer 3-zeiligen Konsolen-App reproduziert, die:

Erstellt eine leere Instanz der Klasse.ruft eine nicht statische Methode (Clone) für die Klasse auf, die als erstes eine Instanz erstellen soll und bereit ist, die Eigenschaften an diese zu übergeben.

Es schlägt zu, als es den zweiten Konstruktor trifft.

Beim Debuggen mit dem .NET-Quellcode sehen wir, dass der Stapelüberlauf in der Guid.NewGuid () erfolgt, die als zweiter Parameter an den Konstruktor übergeben wird. Die eigentliche Codezeile ist der Aufruf des nativen CoCreateGuid () -Aufrufs.

Während es sich also um einen Fehler in CoCreateGuid () handeln könnte, möchten wir unseren Code aus dem Problem entfernen. Mein erster Gedanke ist, den Stapel massiv zu vergrößern und zu prüfen, ob dieser Fehler erneut auftritt. Dann, da ich denke, dass wir alle Anwendungsfälle kontrollieren können, wird der Konstruktor durch die Objektinitialisierung ersetzt - ich denke, dies kann den Druck auf den Stapel entlasten.

Nb. Wir können den Fehler verhindern, indem wir nur die Eigenschaft int aus der Klasse entfernen.