FWD » Core Development » Base Language

We have some customers that have significant investments in .NET support code. This would be 3rd party and/or internal libraries written in .NET and delivered as DLLs. If these were not UI related, we could implement integration with this, on Windows and possibly even on Linux since some form of CLR even runs there. That would probably require initializing the CLR in-process and writing conversion rules to handle the mapping the same way we do with "direct Java access".

This seems an interesting topic.
There are multiple free ways which you can call .NET libraries:
- JVM <--(JNI)--> C/C++ CLR bridge (which is achievable with msclr standard lib) <---> .NET Framework. I think there is a similar approach for .NET code. Obvious, the DLL and JNI bridge needs to be compatible for target system and architecture. The issue is that you need to know the function signatures and convert from Java types to .NET types and vice-versa. For .NET framework on linux systems, we can use mono. Dot NET core apps which you have the source code can be exported directly to native code, but for the black-box .NET core libs, it gets a little bit messy, especially with object types.
- Alternative approach for this is by using gRPC through UDS (two different processes, JVM and CLR). The objects can be exposed in proxies, like how we handle remote objects between FWD client and server.

Constantin, what is your opinion?

I haven't look at what is now available for calling .NET from Java. But, we need to consider where this code will be executed in FWD: server or client? Keep in mind that OpenEdge GUI is a 'client-side' process in FWD terms.

We need to understand also what kind of parameter types and also resources are accessed from .NET. Are there pointers being passed? Files being accessed/written?

The other unknown (at least until we do more research to understand) is the lifetime of .NET objects - when are they destroyed in OpenEdge?

Constantin Asofiei wrote:

I haven't look at what is now available for calling .NET from Java. But, we need to consider where this code will be executed in FWD: server or client? Keep in mind that OpenEdge GUI is a 'client-side' process in FWD terms.

We need to understand also what kind of parameter types and also resources are accessed from .NET. Are there pointers being passed? Files being accessed/written?

The other unknown (at least until we do more research to understand) is the lifetime of .NET objects - when are they destroyed in OpenEdge?

.NET objects on Progress ABL are stored at CLR side and passed to 4GL side through some proxies.
As told in #11284-3, there is no native way to call C# stuff from Java and we need to use JNI for that. On JNI level, you can use the msclr (Windows only) or hostfxr, which is "cross-platform", but only for .NET Core / modern .NET Framework versions.
These dot NET objects seems like they are destroyed at 4GL level, like any other 4GL object.

About Files, this could be a problem if we decide implementing this on server-side.

We can't implement exclusively server-side, for true compatibility the implementation will need to be similar to how we handle native library calls today (.so or .dll). The addition is that we must have the CLR loaded into our process, this is essentially initializing the .NET "virtual machine" in the same process.

If the bridge code solves some problems for us, that is great, we should look at it.

We can add server-side support as well, but that will be very dependent upon the application ensuring it is all thread-safe.

Greg Shah wrote:

We can't implement exclusively server-side, for true compatibility the implementation will need to be similar to how we handle native library calls today (.so or .dll). The addition is that we must have the CLR loaded into our process, this is essentially initializing the .NET "virtual machine" in the same process.

If the bridge code solves some problems for us, that is great, we should look at it.

We can add server-side support as well, but that will be very dependent upon the application ensuring it is all thread-safe.

Ok, that makes sense.
About .NET support, what OE AVM version customer is using?

I have found this if this is helpful:
https://community.progress.com/s/article/000054406

The customer reports using OE 11.7 and ".NET framework 4.7+".

From a conversion POV, I wouldn't want to emit reflection-style code. Instead, I think we need to generate Java interfaces, annotate them with the .NET equivalents (class, method names, .NET parameters maybe), and use these as a proxy for the network call to FWD client. On FWD client, it can be something generic, which will handle both instance management and calls to .NET.

Constantin Asofiei wrote:

From a conversion POV, I wouldn't want to emit reflection-style code. Instead, I think we need to generate Java interfaces, annotate them with the .NET equivalents (class, method names, .NET parameters maybe), and use these as a proxy for the network call to FWD client. On FWD client, it can be something generic, which will handle both instance management and calls to .NET.

Yes, exactly, that is what I have thinking too.

I have done more research on that and I have noticed that when using msclr standard lib with /clr flag on msvc compiler, it will add all the CLR initialization logic in your code. I don't know currently what is the CLR instance scope is, but I think once CLR was loaded, the CLR is kept until the process finishes.
The alternative is using mscoree, which you can manage the CLR manually.

Sources:
- https://codingvision.net/calling-a-c-method-from-c-c-native-process
- https://learn.microsoft.com/sk-sk/cpp/dotnet/overview-of-marshaling-in-cpp?view=msvc-140
- https://stackoverflow.com/questions/15772765/how-to-call-managed-c-methods-from-un-managed-c