Why doesn’t the JNBridgePro for .NET Core proxy tool generate proxy DLLs?

 

 

 

We mentioned in an earlier post that the proxy tool that we provide with our .NET Core components is only used to create proxy JAR files for Java-to-.NET Core projects. For .NET Core-to-Java projects, you should use one of the proxy generation tools ordinarily used with .NET Framework. Why don’t we have a .NET Core proxy tool to create proxy DLLs?

The problem is that .NET Core is missing a crucial API that’s needed to do this. When we generate proxy DLLs using the proxy tools for .NET Framework, we first create the proxy assembly in memory, add the various proxy classes to the in-memory proxy assembly, then write out the complete proxy assembly to disk as a DLL file. While .NET Core does support the creation of in-memory assemblies, it does not provide a way to write them out to disk. There’s a GitHub discussion of why this is the case here.

It turns out that some open-source developers have created a NuGet package, Lokad.ILPack, to address this problem and write in-memory assemblies to disk. We downloaded the package and were unable to get it to work in the context of our proxy generation tool before code freeze, so we decided to leave that capability out and work on it later.  We hope to have a .NET Core-based proxy tool for .NET Core-to-Java projects in an upcoming version, either using this package or some other capability.

In the meantime, you should use the .NET Framework-based proxy generation tools to create proxy DLLs for .NET Core-to-Java projects. The proxy DLLs generated by these tools will work just fine with .NET Core applications. The downside, of course, is that these proxy generation tools only work on Windows, where .NET Framework has been installed. We know that’s an inconvenience, but we hope that in an upcoming release it’ll be a thing of the past.

See more about our support for .NET Core.

As always, do let us know if you have any questions, comments, or suggestions for new features.