NETDEFGEN COPY Files

COPY files that have been generated by the NETDEFGEN utility can contain any of several .NET parameters. The parameters are described below. The same parameters have been added to the ACUCOBOL-GT DISPLAY, CREATE, and Screen Section statements.

To access a .NET assembly, your COBOL program must pass at least the ASSEMBLY-NAME, NAMESPACE, and CLASS-NAME parameters. The rest of the .NET parameters are optional. That is because the compiler extracts these parameters from the COPY file if they are not included in your program. The exception is FILE-PATH, which is never included in the COPY file. If you want to include a FILE-PATH, you must encode it as described in the table below.

You pass .NET parameters when you first instantiate a .NET control in your COBOL program, that is, in the CREATE, DISPLAY, or Screen Section statement.

Note that the returning value of any field in the parameter list can be updated and returned to your COBOL program if desired.

COPY File Parameter Parameter to Pass Required/ Optional Description
NAME ASSEMBLY-NAME Required Filename of assembly, without extension
NAMESPACE NAMESPACE Required Assembly NameSpace
CLASS CLASS-NAME Required Class name
VERSION VERSION Optional Version number of assembly
CULTURE CULTURE Optional Cultural information like language, country, region; default is neutral.
STRONG STRONG-NAME Optional PublicKeyToken; a cryptographic key that is generated by the Microsoft utility "sn.exe". All assemblies that are loaded in the GAC must include a STRONG-NAME key. If an assembly has a key, the compiler automatically retrieves it from the COPY file when it encounters a NAMESPACE/CLASS parameter.
CONSTRUCTOR(n) CONSTRUCTOR Optional if a default constructor exists All classes that result in an object have a constructor, which is a sort of method. When a class is instantiated with a CREATE, DISPLAY, or Screen Section statement in COBOL, this constructor is the first thing that is executed. It is executed once during the instantiation phase of an object.

Constructors, like methods, can have parameters, although most do not. The default constructor usually has no parameters. But if a .NET programmer has written a control that has constructors with parameters, you will see the word "CONSTRUCTOR" in the COPY file, followed by a number and the parameters associated with the constructor. This is called overloading. It occurs when the same method name has different parameters.

Following is an example of a constructor that has been generated by the NETDEFGEN utility:

OBJECT @ASSEMBLY NAME "@My.Assembly" 
VERSION "1.0.0.0" 
CULTURE "neutral" 
STRONG "3f6e8fa90dc2951b" 
NAMESPACE "My.Test.NameSpace" 
CLASS "MyClass" 
CONSTRUCTOR, 0, @CONSTRUCTOR1 
CONSTRUCTOR, 0, @CONSTRUCTOR2 
"BSTR" @value, TYPE 8 
CONSTRUCTOR, 0, @CONSTRUCTOR3 "int" @overloadedconstruct, TYPE 3

Because CONSTRUCTOR1 has no parameters, you can use a CREATE, DISPLAY, or Screen Section entry without a CONSTRUCTOR parameter.

If you want to pass values, then you would select CONSTRUCTOR2 or CONSTRUCTOR3. The following depicts a CONSTRUCTOR parameter in a CREATE statement.

77 MY-ASSEMBLY-HANDLE USAGE IS HANDLE. 
   CREATE "My.Assembly" 
     NAMESPACE IS 
     "My.Test.NameSpace" 
     CLASS-NAME IS "MyClass" 
       CONSTRUCTOR IS CONSTRUCTOR3   
     123456) 
     HANDLE IS MY-ASSEMBLY-HANDLE. 
MODULE identifier MODULE Optional Assemblies can have multiple modules within them; that is, assemblies constructed from other assemblies. MODULE identifies the file where this NameSpace class combination resides. It is used by the runtime to select a module within an assembly.
n/a FILE-PATH

Version 9.0 and above require .Net Framework 4.0, to access remote assemblies create a text file (in the runtime bin directory)called

wrun32.exe.config

Use the following XML in this file.

<configuration> <runtime> <loadFromRemoteSources enabled="true"/> </runtime> </configuration>

The O/S will use this file to allow the local runtime to access a remote assembly.

Optional

By default, the runtime looks for .NET assemblies in the end user's GAC. If it can't find the requested assembly in the GAC, it looks in the same directory as the runtime, "wrun32.exe".

Use FILE-PATH when the assembly that the program must access does not reside in the user's GAC or in the same directory as "wrun32.exe".

To include a FILE-PATH, first create an XML file containing the full file path where the assembly is located. Then in your COBOL program, include the FILE-PATH parameter followed by the full path of an XML file. If the FILE-PATH contains a filename only, the file is loaded from the same directory as the runtime.

Following is an example of a FILE-PATH XML file:

<?xml version="1.0"
    encoding="utf-8" ?> 
<FILESPEC> 
<Assembly>AmortControl</Assembly> 
<Module>amortcontrol.dll</Module> 
<StrongName /> 
<Version>1.0.1242.11216</Version> 
<Culture>neutral</Culture> 
<FilePath>E:\AmortControl\bin\Debug\AmortControl.dll</FilePath> 
</FILESPEC>