SQL Server データベース プロジェクト テンプレートを使用してソリューションを作成すると、Enterprise Developer によって 2 つのプロジェクトが自動的に生成されます。1 つは COBOL プロジェクト、もう 1 つは対応する .Publish プロジェクトです。.Publish プロジェクトは自動的に COBOL プロジェクトを参照します。COBOL プロジェクトは、検証可能な (安全な) アセンブリとしてビルドされるようにプロパティが設定されています。これは、SQL Server にパブリッシュされたアセンブリが SQL CLR 環境で実行されるようにするために必要です。
単一プロジェクトのソリューション構造では、プログラムおよびストアド プロシージャをソリューション内の単一プロジェクトに配置します。すべてが 1 つのアセンブリに含まれるため、ディプロイが容易になります。プロジェクト参照も手続きポインターも必要ありません。この編成は、自己完結型のシンプルなアプリケーションに最適です。より大規模で多様なアプリケーションには、複数プロジェクトの構成が適しています。
複数プロジェクトのアプローチでは、タイプに応じてコードをより論理的にグループ化できます。たとえば、関連するプログラムのセット、および関連するストアド プロシージャのセットを含むプロジェクトを作成して、コードを整理できます。また、各プロジェクトにそれぞれ固有のアセンブリがありますが、パブリッシュ処理に含まれるのは変更されたアセンブリのみであるため、ディプロイされるアプリケーションのサイズおよびパブリッシュに要する時間の面でもより効率的です。ただし、コードで参照および手続きポインターを適切に構成できるだけの知識が要求されます。
複数プロジェクトのソリューション構造は柔軟性に優れています。たとえば、すべてのストアド プロシージャ コードを 1 つの .NET COBOL プロジェクトに配置し、SPD ファイルおよびそれに関連して生成された COBOL ラッパーを保持する別の .NET COBOL クラス ライブラリ プロジェクトを作成できます。また、ストアド プロシージャをバッチ ジョブから呼び出す COBOL ネイティブ プロジェクトを追加することもできます。ストアド プロシージャごとに個別の .NET COBOL プロジェクトを作成することもできます。
複数プロジェクトのソリューションでは、使用されているアセンブリを識別する参照や手続きポインターを定義する必要があります。たとえば、1 つ目のアセンブリから 2 つ目のアセンブリのプログラムを呼び出す場合、1 つ目のアセンブリで 2 つ目のアセンブリを参照するか、手続きポインターを使用してロードする必要があります。これにより、2 つ目のアセンブリに含まれているルーチンを実行時に見つけられるようになります。