我们最近在代码中遇到了一个错误，这是由于与非 Silverlight 环境相比 DevForce 在 Silverlight 下的行为方式存在细微差异造成的。我们发现当 DevForce 在 Silverlight 中引发“所有属性已更改”事件时，它是通过在 PropertyChanged 事件中使用 string.Empty 来实现的。但是，在非 Silverlight 中使用 null 代替。这对我们来说并没有那么难解决——我们可能应该一直注意null 或string.Empty。但这让我们担心是否还有其他类似的细微差异需要我们注意。
Silverlight 和非 Silverlight 之间还有其他已知的区别吗？显然存在一些差异，例如 Silverlight 不允许同步查询……但这是有据可查的。我正在寻找这样的小东西，它们可能会破坏以前在 Silverlight 中运行良好的代码。
【问题讨论】：
标签： silverlight devforce
很抱歉您遇到了 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 的任何特定领域有任何疑问或遇到任何意外的环境差异，请告诉我们。
【讨论】：