我们最近在我们的代码中遇到了一个错误，该错误是由于与非Silverlight环境相比，DevForce在Silverlight下的行为方式存在细微差别。我们发现当DevForce提出“所有属性已经发生变化”的困难时。 Silverlight中的事件，它通过在PropertyChanged事件中使用string.Empty来实现。但是，在非Silverlight中使用null代替。这对我们来说并不是很难解决 - 我们可能应该一直关注null或string.Empty。但令我们担心的是，如果还有其他微妙的差异，我们应该留意。
Silverlight和非Silverlight之间是否还有其他已知的差异？显然存在一些差异，例如Silverlight不允许同步查询......但这有很好的文档记录。我正在寻找像这样的小东西，它可能会破坏以前在Silverlight中运行良好的代码。
答案 0 :(得分：1)
抱歉，您遇到了PropertyChanged问题。这种分歧实际上是由于SL DataForm中的旧错误引起的，但它从未在DevForce中重新解决，因为MS文档确实说null和空字符串都做同样的事情。 FWIW，DF在所有非完整.NET环境中使用空字符串。
我们没有关于这些微妙差异的任何文件。通常，大多数环境差异导致不同的表面积，通常具有减少的API。因此，您注意到同步方法只能在.NET程序集中找到，而您可以在SL程序集中找到与XAP相关的API。其他“缺失”或更改的功能将是文件I / O和.config文件处理。
通常，DF尝试合理化跨环境的API和行为，尽管在底层实现中可能存在细微的差异或性能影响。例如，WCF，组合（MEF），序列化和反射是我们发现的一些领域并不总是在不同的环境中工作，尽管我们已经尝试在DevForce中缓解这些因素，因此应用程序看不到的问题。 DF还在非.NET环境中对某些属性（主要用于ODATA和数据注释）进行了shim / dummy实现，如果您期望真实类型，这可能会导致问题。
我已经扫描了一些可能不明显的差异：1）在非.NET中克隆时需要无参数构造函数，2）仅使用ProvideEntityAspect和ProvideComplexAspect属性进行编译时验证在.NET中，3）尝试使用FIPS参数集进行加密/解密将在非.NET中抛出NotSupportedException。
设计时支持也存在差异。在SL中，当使用ECS或使用基于代码优先模型的设计时数据时，VS将抛出奇怪的安全性和序列化异常。
我还应该注意，如果你正在对SL代码进行.NET单元测试，你不能认为代码也可以在SL中运行。你真的需要在SL中测试以避免意外。
如果您对DevForce的任何特定区域有疑问或遇到任何意外的环境差异，请告知我们。