Current Revision posted to Visual COBOL Knowledge Base by evank on 6/19/2015 5:53:30 PM
Problem:
I want to run .NET COBOL applications on my workstation without COBOL Server installed locally. How do I configure this to run a .NET COBOL application from a network COBOL Server installation?
Resolution:
To run a .NET COBOL application from a network server
You can deploy a .NET managed COBOL application on a network server so that all workstations that are mapped to the server can run the application without the need to install COBOL Server 2012 locally on each workstation.
Note: Throughout this topic, the installation folders should include the correct name of the targeted deployment product - COBOL Server, COBOL Server 2012, or COBOL Server 2013.
Before you can configure your .NET COBOL application, ensure that:
COBOL Server 2012 is installed and licensed on the server.
The workstations that are accessing the server on the network have the necessary permissions. (see Trust issues below)
If your application also uses native code components, you need to setup the licensing and create some shared folders - see To run a native COBOL application from a network server in the documentation.
Note: The following folders in the installation of COBOL Server 2012 on the server include:
%ProgramFiles(x86)%\Micro Focus\COBOL Server 2012\bin contains the native run-time files for 32-bit machines
%ProgramFiles(x86)%\Micro Focus\COBOL Server 2012\bin64 contains the native run-time files for 64-bit machines
%ProgramFiles(x86)%\Micro Focus\COBOL Server 2012\redist\v4.0 contains the .NET Framework version 4.0 of run-time assemblies
%ProgramFiles(x86)%\Micro Focus\COBOL Server 2012\redist\v2.0 contains the .NET Framework version 2.0 of run-time assemblies
.NET search mechanism:
If you are running a .NET managed code application from the network server, then you need to make the appropriate .NET run-time assemblies available to your application.
The mechanism for locating and loading .NET assemblies at run-time is different than for native .dlls in that the system PATH is not used when locating dependent assemblies.
For locating the required COBOL run-time assemblies they will have to be placed into the same folder containing your application files.
Therefore you must either copy the appropriate run-time assemblies from either the redist\v4.0 or redist\v2.0 folders of COBOL Server into your application folder or copy your application files into the appropriate COBOL Server redist\* folder.
You should then create a network share for the folder containing your application files and COBOL run-time assemblies and make this available to your workstations.
If using the COBOL Server redist\* folders for your application then share the server folder %ProgramFiles(x86)%\Micro Focus\COBOL Server 2012\redist\v4.0.
If your application targets .NET Framework version 2.0, you need to map the V2.0 subfolder instead.
This rule does not apply to assemblies that are loaded from your application using the standard COBOL CALL mechanism. In the case where the application does:
set <procedure-pointer> to entry "progname"
or
call "progname"
Programs loaded in this fashion will be located via PATH setting but for ease of deployment it is recommended that you keep all dependent .NET assemblies within the same folder.
If you will be setting PATH to locate called assemblies then you should set this in your app.config file directly instead of at the system level.
Example app.config file:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<configSections>
<!--The following code declares a section group for application configuration -->
<sectionGroup name="MicroFocus.COBOL.Application">
<section name="Switches" type="System.Configuration.NameValueSectionHandler" />
<section name="Environment" type="System.Configuration.NameValueSectionHandler" />
</sectionGroup>
<!--The following code declares a section group for run-time configuration -->
<sectionGroup name="MicroFocus.COBOL.Runtime">
<section name="Tunables" type="System.Configuration.NameValueSectionHandler" />
<section name="Switches" type="System.Configuration.NameValueSectionHandler" />
</sectionGroup>
</configSections>
<MicroFocus.COBOL.Application>
<Switches />
<Environment>
<add key="PATH" value="F:\myappfiles;%PATH%" />
</Environment>
</MicroFocus.COBOL.Application>
</configuration>
Trust issues:
A network drive only has "local intranet" permissions by default, which means you are very restricted as to what you can do with it. So, to run the application you will need to elevate its security level. One option is to add an app.config file to the application which includes the following section:
<runtime>
<loadFromRemoteSources enabled="true"/>
</runtime>
Another option is to use the Microsoft caspol utility on the share containing your application. If you do a google search on "caspol network drive full trust" then you will find some helpful links.
Below is an example of an app.config file that can be used to run a .NET COBOL application from a network share while providing Full Trust to assemblies on the network share.
Example app.config file:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<configSections>
<!--The following code declares a section group for application configuration -->
<sectionGroup name="MicroFocus.COBOL.Application">
<section name="Switches" type="System.Configuration.NameValueSectionHandler" />
<section name="Environment" type="System.Configuration.NameValueSectionHandler" />
</sectionGroup>
<!--The following code declares a section group for run-time configuration -->
<sectionGroup name="MicroFocus.COBOL.Runtime">
<section name="Tunables" type="System.Configuration.NameValueSectionHandler" />
<section name="Switches" type="System.Configuration.NameValueSectionHandler" />
</sectionGroup>
</configSections>
<runtime>
<!--The following line provides Full Trust for assemblies loaded from a network share -->
<loadFromRemoteSources enabled="true"/>
</runtime>
</configuration>
