シリアル化のガイドライン

[アーティクル]
09/17/2008

コンパイル後はクラスをシリアル化可能にすることはできないため、新しいクラスのデザイン時に、シリアル化について検討する必要があります。その場合、このクラスをアプリケーションドメイン間で送信する必要があるかどうか、このクラスをリモート処理で使用する可能性があるかどうかについて検討します。さらに、このクラスの用途、たとえば、ユーザーがシリアル化の必要な新しいクラスをこのクラスから派生する可能性があるかどうかについても検討する必要があります。判断に迷った場合は、クラスをシリアル化可能としてマークします。次のいずれかの条件に当てはまる場合を除き、すべてのクラスをシリアル化可能としてマークしておくことをお勧めします。

クラスがアプリケーションドメインを越える可能性がない。クラスをシリアル化する必要がなく、アプリケーションドメインを越える必要がある場合には、クラスを MarshalByRefObject から派生します。
クラスが、そのクラスの現在のインスタンスだけに適用できる特別なポインタを保持している。たとえば、クラスにアンマネージメモリハンドルまたはアンマネージファイルハンドルが含まれている場合は、これらのファイルを NonSerializedAttribute 属性でマークするか、このクラスをシリアル化しないようにします。
クラスのデータメンバに機密情報が格納されている。この場合は、クラスはシリアル化可能としてマークしますが、機密情報を格納するそれぞれのデータメンバは NonSerializedAttribute 属性でマークすることをお勧めします。別の方法として、ISerializable インターフェイスを実装し、必要なフィールドだけをシリアル化することもできます。

クラスをシリアル化可能としてマークする場合のセキュリティへの影響に注意してください。クラスやクラスコンストラクタの CodeAccessPermission の Link Demand や Inheritance Demand は、同じ CodeAccessPermission に対応する要求を実装する既定のシリアル化またはカスタムシリアル化によって回避できます (詳細については、SecurityAction 列挙型を参照してください)。クラスにアクセス許可の Link Demand がある場合は、ランタイムは直接の呼び出し元だけをチェックして、呼び出し元にそのアクセス許可が付与されているかどうかを確認します。.NET Framework クラスライブラリのコードは、Microsoft の厳密な名前を使用して署名されており、常に完全な信頼が付与されています。すべてのコードで、完全な信頼が付与されているコードを使用して、リンク時のセキュリティチェックを回避できます。たとえば、シリアル化の場合は、必要なシリアル化アクセス許可を持たない悪意のあるコードが、完全に信頼された BinaryFormatter などの .NET Framework フォーマッタを呼び出すことによって、リンク確認要求のアクセス許可のチェックを回避できます。

Share via

シリアル化のガイドライン

関連項目

その他の技術情報

その他のリソース