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

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

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

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

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

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

参照

概念

セキュリティとシリアル化

その他の技術情報

バイナリ シリアル化
リモート オブジェクト
XML シリアル化および SOAP シリアル化