2016-08-05 7 views
0

DevlightがSilverlight環境下で動作する方法とSilverlight環境以外の環境との微妙な違いによって引き起こされたコードのバグを最近発見しました。 DevForceがSilverlightで「すべてのプロパティが変更されました」イベントが発生した場合、PropertyChangedイベントでstring.Emptyを使用することにより、DevForceが「すべてのプロパティが変更されました」イベントが発生するという難しい方法を発見しました。ただし、Silverlight以外の場合はnullが代わりに使用されます。これは私たちの最終的な解決策ではありませんでした。おそらく、nullまたはstring.Emptyのいずれかを見ていたはずです。しかし、このような微妙な違いがあるかどうか心配しています。DevForceにSilverlightとSilverlight以外のプラットフォームの違いは何ですか?

このようなSilverlightとSilverlight以外の違いは他にありますか?明らかに、同期クエリを許可しないSilverlightなどいくつかの違いがありますが、それは十分に文書化されています。私はこれまでSilverlightでうまく機能していたコードを壊すかもしれない小さなものを探しています。

答えて

1

申し訳ありませんが、PropertyChangedの問題が発生しました。その違いは実際にはSL DataFormの古いバグのために起こりましたが、MSのドキュメントでは空文字列と空文字列の両方が同じことを言っているので、DevForceで再度扱われることはありません。 FWIWでは、DFはすべての非フル.NET環境で空文字列を使用します。

これらの微妙な違いに関するドキュメントはありません。一般に、ほとんどの環境差は異なる表面積をもたらし、通常はAPIが減少します。したがって、同期メソッドは.NETアセンブリでしか見つかりませんが、SLアセンブリではXAP関連のAPIが見つかります。他の「欠落」や変更された機能は、ファイルI/Oや.configファイルの処理のようなものです。

一般的に、DFは環境全体でAPIとビヘイビアを合理化しようとしますが、基本的な実装では微妙な違いやパフォーマンスへの影響があります。たとえば、WCF、合成(MEF)、シリアライゼーション、リフレクションは、DevForce内でこれらを緩和しようとしていますが、常に同じ環境で動作するとは限らないことがわかりました。問題。 DFはまた、非.NET環境でのいくつかの属性(主にODATAやデータ注釈)のシム/ダミー実装を備えています。実際の型が必要な場合には問題を引き起こす可能性があります。

1)非.NETでのクローン作成時にパラメータのないコンストラクタが必要、2)ProvideEntityAspectおよびProvideComplexAspect属性の使用に関するコンパイル時検証が完了している.NETでのみ、3)FIPSパラメータセットで暗号化/復号化を行うと、非.NETにNotSupportedExceptionがスローされます。

デザイン時サポートにも違いがあります。 SLでは、ECSを使用しているとき、またはコードの最初のモデルに基づいて設計時データを使用しているときに、VSによって奇妙なセキュリティとシリアライゼーションの例外がスローされます。

また、SLコードの.NETユニットテストを行っている場合、そのコードもSLで動作するとは考えられません。あなたは本当に驚きを避けるためにもSLでテストする必要があります。

DevForceの特定の領域について疑問がある場合、または予期しない環境に遭遇した場合は、当社にご連絡ください。

+0

詳細な説明をありがとうございます。それは大いに役立ちます。私はこの情報を私のチームに戻し、さらに詳しい情報が必要なのかどうかを知らせます...しかし、あなたはそれをうまくカバーしたと思います。 –

関連する問題