Frage

Ich habe einige Beiträge zu Änderungen in .NET 3.5 SP1 gesehen, bin aber auf einen gestoßen, für den ich gestern noch keine Dokumentation gesehen habe.Ich hatte Code, der auf meinem Computer einwandfrei funktionierte, von VS, über die msbuild-Befehlszeile usw., aber auf dem Build-Server (mit .NET 3.5 RTM) schlug er fehl.

[XmlRoot("foo")]
public class Foo
{
    static void Main()
    {
        XmlSerializer serializer = new XmlSerializer(typeof(Foo));

        string xml = @"<foo name='ack' />";
        using (StringReader sr = new StringReader(xml))
        {
            Foo foo = serializer.Deserialize(sr) as Foo;
        }
    }

    [XmlAttribute("name")]
    public string Name { get; set; }

    public Foo Bar { get; private set; }
}

In SP1 läuft der obige Code einwandfrei.In RTM erhalten Sie eine InvalidOperationException:

Es kann keine temporäre Klasse generiert werden (Ergebnis=1).Fehler CS0200:Die Eigenschaft oder der Indexer „ConsoleApplication2.Foo.Bar“ kann nicht zugewiesen werden – sie ist schreibgeschützt

Damit es unter RTM läuft, muss natürlich nur [XmlIgnore] zur Bar-Eigenschaft hinzugefügt werden.

Mein Google Fu ist offenbar nicht in der Lage, eine Dokumentation dieser Art von Änderungen zu finden.Gibt es irgendwo eine Änderungsliste, die diese Änderung auflistet (und ähnliche Änderungen unter der Haube, die auftauchen und „Gotcha“ rufen könnten)?Ist das ein Fehler oder eine Funktion?

BEARBEITEN:Wenn ich in SP1 a hinzugefügt habe <Bar /> Element hinzufügen oder [XmlElement] für die Bar-Eigenschaft festlegen, wird es nicht deserialisiert.Es schlägt vor SP1 nicht fehl, wenn versucht wird, zu deserialisieren – es löst eine Ausnahme aus, wenn der XmlSerializer erstellt wird.

Dadurch tendiere ich eher zu einem Fehler, insbesondere wenn ich ein [XmlElement]-Attribut für Foo.Bar festlege.Wenn es nicht in der Lage ist, das zu tun, was ich von ihm verlange, sollte es eine Ausnahme auslösen, anstatt Foo.Bar stillschweigend zu ignorieren.Andere ungültige Kombinationen/Einstellungen von XML-Serialisierungsattributen führen zu einer Ausnahme.

BEARBEITEN:Vielen Dank, TonyB. Ich wusste nicht, wie man den Speicherort für temporäre Dateien festlegt.Für diejenigen, die in Zukunft auf ähnliche Probleme stoßen, benötigen Sie ein zusätzliches Konfigurationsflag:

<system.diagnostics>
  <switches>
    <add name="XmlSerialization.Compilation" value="1" />
  </switches>
</system.diagnostics>
<system.xml.serialization>
  <xmlSerializer tempFilesLocation="c:\\foo"/>
</system.xml.serialization>

Selbst wenn ein [XmlElement]-Attribut für die Bar-Eigenschaft festgelegt wurde, wurde es in der generierten Serialisierungsassembly nicht erwähnt – was dies ziemlich eindeutig in den Bereich eines stillschweigend verschluckten Fehlers (auch bekannt als Bug) einordnet.Entweder das, oder die Designer haben entschieden, dass [XmlIgnore] für Eigenschaften, die nicht festgelegt werden können, nicht mehr erforderlich ist – und das würde man in den Versionshinweisen erwarten, Änderungslisten, oder der XmlIgnoreAttribute-Dokumentation.

War es hilfreich?

Lösung

Wird die foo.Bar-Eigenschaft in SP1 ordnungsgemäß deserialisiert?

In Versionen vor SP1 konnten Sie das Objekt nicht deserialisieren, da die Set-Methode der Bar-Eigenschaft privat ist und der XmlSerializer daher keine Möglichkeit hat, diesen Wert festzulegen.Ich bin mir nicht sicher, wie SP1 das hinbekommt.

Sie könnten versuchen, dies zu Ihrer web.config/app.config hinzuzufügen

<system.xml.serialization> 
  <xmlSerializer tempFilesLocation="c:\\foo"/> 
</system.xml.serialization> 

Dadurch wird die vom XmlSerializer generierte Klasse in c:\foo abgelegt, sodass Sie sehen können, was sie in SP1 im Vergleich zu RTM tut

Andere Tipps

Dieses neue (?) Verhalten gefällt mir eher, weil das XML-Dokument Bar nicht erwähnt und der Deserialisierer daher nicht einmal versuchen sollte, es festzulegen.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top