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

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

• クラスがアプリケーション ドメインを越える可能性がない。クラスをシリアル化する必要がなく、アプリケーション ドメインを越える必要がある場合には、クラスを MarshalByRefObject から派生します。

• クラスが、そのクラスの現在のインスタンスだけに適用できる特別なポインターを保持している。たとえば、クラスにアンマネージ メモリ ハンドルまたはアンマネージ ファイル ハンドルが含まれている場合は、これらのファイルを NonSerializedAttribute 属性でマークするか、このクラスをシリアル化しないようにします。

• クラスのデータ メンバーに機密情報が格納されている。この場合は、クラスはシリアル化可能としてマークしますが、機密情報を格納するそれぞれのデータ メンバーは NonSerializedAttribute 属性でマークすることをお勧めします。別の方法として、ISerializable インターフェイスを実装し、必要なフィールドだけをシリアル化することもできます。

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

参照

その他のリソース

バイナリ シリアル化
Remote Objects
XML シリアル化および SOAP シリアル化
Security and Serialization