私は、一連の WIN32 API 呼び出しを使用し、安全でないコードを必要とするプロジェクトに取り組んでいます。ベスト プラクティスの観点から、メイン アプリケーションを安全に保ちながら、/unsafe スイッチでコンパイルされた独自の DLL にこのコードを分離する必要がありますか?
別の言い方をすれば。/unsafe スイッチを使用してプロジェクトをコンパイルしない理由はありますか? 潜在的なリスクはありますか?
アセンブリは、定義上、.NET で個別にバージョン管理可能で再配布可能なコードの最小単位です。したがって、私が自問する最初の質問は、「安全でないコードの新しいバージョンを作成して、アプリケーションとは別に配布したいと思うだろうか?」ということです。
答えが「はい」の場合は、必ずそのコードを独自のアセンブリに配置してください。
答えが「いいえ」の場合は、他の要因を検討してください。たとえば、"従来の" .NET セキュリティでは、同じ appdomain 内でさまざまな信頼レベルでさまざまなアセンブリを実行できます。(最新の CLR では、システムははるかに単純です。完全に信頼されたコードだけがあり、他のすべては appdomain に付与された信頼のレベルで実行されます。) 安全でないことを行うコードは完全に信頼される必要がありますが、単に呼び出すコードは安全でないコードが正しいアクセス許可のセットをアサートする場合、信頼性が低くなる可能性があります。
安全なコードが部分的に信頼されているという状況に陥ることはありますか? その場合は、必ずアンセーフ コードを独自のアセンブリに配置し、このアセンブリが完全に信頼されている必要があることを文書化してください。
あなたがそのような状況にないのであれば、安全でないコードをそれ自体のアセンブリに入れる気はありません。
ただし、単純に未加工の win32 呼び出しを公開するのではなく、アンマネージ コードの上に快適なマネージ オブジェクト モデルを作成する傾向があります。たとえば、先日、C# から厳密な名前検証用の win32 API を呼び出す必要がありましたが、それらを適切に公開する小さなライブラリを作成し、すべての厄介な相互運用機能の詳細をクラスのプライベートな内部に抽象化しました。