Welche Unterschiede gibt es in DevForce zwischen Silverlight- und Nicht-Silverlight-Plattformen?

Question

Wir haben kürzlich einen Fehler in unserem Code gefunden, der durch einen subtilen Unterschied in der Funktionsweise von DevForce unter Silverlight im Vergleich zu Nicht-Silverlight-Umgebungen verursacht wurde. Wir haben auf die harte Tour herausgefunden, dass wenn DevForce in Silverlight das Ereignis "Alle Eigenschaften haben sich geändert" ausgelöst hat, indem es im PropertyChanged-Ereignis string.Empty verwendet. Bei Nicht-Silverlight wird stattdessen null verwendet. Dies war nicht so schwer von einer Lösung für unser Ende - wir hätten wahrscheinlich die ganze Zeit nach null oder string.Empty Ausschau halten müssen. Aber es hat uns beunruhigt, wenn es andere feine Unterschiede gibt, auf die wir achten sollten.

Gibt es noch andere bekannte Unterschiede zwischen Silverlight und Nicht-Silverlight? Offensichtlich gibt es einige Unterschiede wie Silverlight synchrone Abfragen nicht erlaubt ... aber das ist gut dokumentiert. Ich suche nach kleinen Dingen wie diesem, die Code beschädigen könnten, der vorher in Silverlight gut funktioniert hat.

Answer 1

Leider ist das PropertyChanged-Problem aufgetreten. Diese Divergenz ist tatsächlich auf einen alten Fehler in der SL DataForm zurückzuführen, wurde aber in DevForce nie wieder angesprochen, da die MS-Dokumentation besagt, dass sowohl die Null als auch die leere Zeichenfolge dasselbe tun. FWIW, DF verwendet den leeren String hier in allen nicht vollständigen .NET-Umgebungen.

Wir haben keine Dokumentation über diese feinen Unterschiede. Im Allgemeinen führen die meisten Umgebungsunterschiede zu einer anderen Oberfläche, normalerweise mit einer reduzierten API. Wie Sie festgestellt haben, sind die synchronen Methoden nur in den .NET-Assemblys zu finden, während Sie in den SL-Assemblies XAP-bezogene APIs finden. Andere "fehlende" oder geänderte Features wären Dinge wie Datei-I/O und .config-Dateibehandlung.

Im Allgemeinen versucht DF, die APIs und Verhaltensweisen in verschiedenen Umgebungen zu rationalisieren, obwohl es in den zugrunde liegenden Implementierungen zu geringfügigen Unterschieden oder Leistungseinbußen kommen kann. Zum Beispiel WCF, Komposition (MEF), Serialisierung und Reflektion sind ein paar Bereiche, von denen wir herausgefunden haben, dass sie in verschiedenen Umgebungen nicht immer gleich funktionieren, obwohl wir versucht haben, diese innerhalb von DevForce zu mildern, so dass Apps den Probleme. DF verfügt auch über Shim/Dummy-Implementierungen für einige Attribute (hauptsächlich für ODATA und Datenanmerkungen) in Nicht-.NET-Umgebungen, die Probleme verursachen könnten, wenn Sie die echten Typen erwarten.

Ich habe nach einigen Unterschieden gesucht, die möglicherweise nicht offensichtlich sind: 1) Wenn ein Cloning in non.NET, 2) eine kompilierungszeitliche Validierung der Verwendung der ProvideEntityAspect- und ProvideComplexAspect-Attribute erfolgt, ist ein parameterloser Konstruktor erforderlich Nur in .NET, 3) Versuche, die Verschlüsselung/Entschlüsselung mit dem FIPS-Parametersatz durchzuführen, werden eine NotSupportedException in non.NET auslösen.

Es gibt auch Unterschiede in der Entwurfszeitunterstützung. In SL werden seltsame Sicherheits- und Serialisierungsausnahmen von VS ausgelöst, wenn das ECS verwendet wird oder Entwurfszeitdaten basierend auf einem ersten Codemodell verwendet werden.

Ich sollte auch beachten, dass Sie, wenn Sie .NET-Unit-Tests Ihres SL-Codes durchführen, nicht davon ausgehen können, dass der Code auch in SL funktioniert. Sie müssen wirklich in SL auch testen, um Überraschungen zu vermeiden.

Wenn Sie Fragen zu bestimmten Bereichen von DevForce haben oder auf unerwartete Umgebungsunterschiede stoßen, lassen Sie es uns wissen.