Working with .NET COBOL Projects

When you create a solution using the SQL Server Database project template, Enterprise Developer automatically generates two projects - a COBOL project and a corresponding .Publish project. The .Publish project automatically references the COBOL project. The COBOL project properties are set to build the project as a verifiable (or safe) assembly. This is required to ensure that any assembly published to SQL Server runs in the SQL CLR environment.

Tip: If you were to subsequently add another COBOL project and corresponding .Publish project to an existing SQL Server Database solution, you must manually set the properties for the COBOL project to build as verifiable. For more information, see To set project properties to build verifiable code.

Single-project Solution

The single-project solution structure puts the programs and stored procedures into a single project within the solution. This is a deployment advantage because everything is in a single assembly. No project references or procedure pointers are required. This organization is best for simple, self-contained applications. Larger, more diverse applications are best organized in a multi-project configuration.

In the Enterprise Developer Mainframe Samples Browser, we provide two examples of using multiple COBOL projects in a single solution. To see these, open the following samples from the Mainframe Samples > SQL list:

  • OESQL - JCL Calling SP Single-project by Literal
  • OESQL - JCL Calling SP Single-project by Data Name

Multi-project Solution

The multi-project approach enables you to group types of code more logically. For example, you can organize your code by creating projects that include sets of related programs, and sets of related stored procedures. Each project has its own assembly distinct from the others. Because the publishing process includes only assemblies that have changed, this method of organization can improve efficiency with regard to the size of the deployed application and the time required to publish. This method does require knowledge of the code sufficient to configure the appropriate references and procedure pointers.

A multi-project solution structure provides flexibility. For example, you could put all your stored procedure code into one .NET COBOL project, and create a separate distinct .NET COBOL Class Library project in which to keep your SPD files and their associated generated COBOL wrappers. You could also add a COBOL native project that calls your stored procedure from a batch job. You might even want a separate .NET COBOL project for each stored procedure!

In multi-project solutions, you must define references or procedure pointers that identify the assemblies used, that is, when one assembly calls a program in a second assembly, the first assembly must either reference the second assembly or use a procedure pointer to load the second assembly. This ensures that routines contained in the second assembly are found at run time.

Tip: To learn more about references and procedure pointers, see Issuing COBOL Calls from within SQL CLR Stored Procedures.
Important: Each .NET COBOL Class Library project you include in the solution must be referenced by the .Publish project in the same solution. This ensures that all the code executed by stored procedures is appropriately deployed to SQL Server. See To add a project reference to a .Publish project for instructions.

In the Enterprise Developer Mainframe Samples Browser, we provide two examples of using multiple COBOL projects in a single solution. To see these, open the following samples from the Mainframe Samples > SQL list:

  • OESQL - JCL Calling SP Multi-project by Literal
  • OESQL - JCL Calling SP Multi-project by Data Name