Created On:  27 June 2011

Problem:

Having the runtime installed in a primary machine, like:

my-firstmachine:C:\Program Files\Micro Focus\Acucbl900\AcuGT\bin.

The .NET DLL is sitting in this same folder as well.

There is a programs folder in a second machine which is been mapped as Z: drive

my-secondmachine:C:\objects

Changing to the mapped drive and executing the following command, it works perfectly, creating the object.

Z:>"c:\Program Files\Micro Focus\Acucbl900\AcuGT\bin\wrun32" my-program

But, doing:

Z:>\\my-firstmachine\c\"Program Files\Micro Focus\Acucbl900\AcuGT\bin\wrun32" myprogram

It executes the cobol program but when it trys to create the object it generates an error "There was a problem with one of .NET support libraries.NET assemblies cannot be loaded"

This same error happens if the cobol object is copied to the /bin directory, then maping the Acu/bin directory of my-firstmachine from a third one as Y: like: "my-firstmachine\C\Program Files\Micro Focus\Acucbl900\AcuGT"; Executing: C:\>y:\wrun32 y:\myprogram, it executes the cobol object but it crashes when tries to create the .NET object.

Resolution:

This is not a runtime but a security/permissions problem. There is a workaround to avoid this behavior which is to use the --a2n runtime option

--a2n 
 Indicates to use the AcuToNet.dll method of .NET support. Prior to version 9, this interface was used to provide .NET support. By default, this interface is no longer needed in versions 9 or higher of ACUCOBOL-GT. A new internal method of .NET support was added to version 9 that enables greater .NET support than what could be achieved with the previous AcuToNet.dll method.  
 
If you experience issues with the new method of .NET support, you can revert back to the previous method by using this runtime option. There are other steps you must also perform. See section 5.5.15 of the Guide to Interoperating with ACUCOBOL-GT.

But the final solution to this problem is to use the Code Access Security
Policy Tool (CasPol.exe).
 
CasPol can be used to modify security policy for different policy levels.  You can use it to add an assembly to the full trust assembly list for a specific policy level.
 
If you are getting an error it is probably because you are getting a security exception under the covers.
 
Executing .Net code via a UNC or network reduces the permission set and in effect executes the code in "local intranet" zone.
 
You can give it FullTrust for the share you are using.  If the UNC path is \\my-machine
for example:
 
    CasPol.exe -m -pp off -addgroup 1.2 -url file://///my-machine/c/* FullTrust
 
After giving \\my-machine FullTrust the program ran using UNC paths.
 
CasPol.exe Located in C:\Windows\Microsoft.NET\Framework\v2.0.50727
 
The options to CasPol.exe tested on this problem are:
 
-m Modify the machine level of the policy.  This is needed since the machine level is where all of the default policy lives.
 
-pp off Disables prompting, to enable use -pp on
 
-addgroup 1.2 Add a code group under group 1.2.  In the default policy, group 1.2 is the LocalIntranet group, so the new code group that we are creating will only be checked if the file comes from the intranet.
 
-url file://///my-machine/c/*
     The membership condition for the new code group should be a UrlMembershipCondition,
and it should match anything with a URL that start with file://///my-machine/c, meaning that any file on the \\my-machine\c share will match this code group.
 
FullTrust The permission set to grant assemblies that match the code group.  In this
case, FullTrust.
 
To list the groups or to see the group that you added:
 
    CasPol -l
 
If the group you added shows up in the list as something like 1.2.3 then to remove
group 1.2.3 for example:
 
    CasPol -remgroup 1.2.3
 
See the following links for more information on CasPol.exe:
 
http://blogs.msdn.com/b/shawnfa/archive/2004/12/30/344554.aspx
http://msdn.microsoft.com/en-us/library/cb6t8dtz(v=vs.80).aspx
Incident #2507678