At run time, your COBOL program transparently communicates with an interface file called "AcuToNet.dll". This interface starts the .NET CLR, loads the requisite .NET assemblies and event handlers, executes .NET assembly methods, works with properties, and returns the results to the COBOL program.
The ACUCOBOL-GT to .NET bridging interface is delivered in compiled MSIL format. Any time a .NET assembly or "AcuToNet.dll" is loaded, it undergoes an additional compilation in the Microsoft Just-In-Time (JIT) compiler. This can raise questions about performance and whether it's possible to create native code "executables" in .NET.
Microsoft provides a tool in the .NET Framework directory called the Native Image Generator ("NGen.exe") that can be used for this purpose. This utility compiles an assembly into a "native image". You could run the NGen utility on "AcuToNet.dll", located in the ACUCOBOL-GT /bin directory. NGen will compile and place it in the GAC under the same name. To avoid confusion you could rename the original file to "ORIG_AcuToNet.dll". Then when the CLR loads the assembly, it will check the cache to see if a precompiled version exists, and if it does, it will load that.
Although you might think this will improve performance, there a number of drawbacks to consider (including maintenance issues), and you may not obtain the performance improvement you expect either. NGen creates a native image for a hypothetical machine architecture. The advantage is that it runs on any x86 processor, for example. However, when the JIT compiler executes, it takes the specific machine it's running on into account and makes appropriate optimizations. The result is that assemblies dynamically compiled at run time often out perform precompiled assemblies.
Another drawback is that changes to a system's hardware configuration or operating system (like service pack updates) often invalidate the precompiled assembly.