Category: Java/.NET Runtime
Which files do I need to deploy?
In addition to whatever assemblies you created, you will have to deploy the Codemesh runtime library. As described in the architecture section, the runtime consists of a managed and an unmanaged component. You need to deploy both components. Everything you need can be found in the dotnet directory of your JuggerNET distribution. This directory contains the following files:
|netrt.dll||The "weakly named" managed Codemesh runtime library.|
|netrtsn.dll||The strongly named managed Codemesh runtime library.|
|msvcr71.dll||One part of the Microsoft C++ runtime.|
|msvcp71.dll||Another part of the Microsoft C++ runtime.|
|xmogrt.dll||The unmanaged C++ Codemesh runtime library.|
When you build your own project, you have to link with one of the two managed runtime libraries (netrt.dll or netrtsn.dll). It's important that you link with one and only one of them! Whichever one you choose at development time is the one that you have to deploy with your application. The other one is not necessary.
Win32 You also have to deploy all three unmanaged libraries because the managed library relies on them at runtime. You can simply co-locate them with your .NET modules. Don't confuse the deployment requirement with a development requirement: you do not have to add the unmanaged libraries to your .NET projects (actually, you can't; Visual Studio won't allow you to do that).
Win64 For 64-bit Windows, we provide a different version of xmogrt.dll in a subfolder of the
cpp\windows-all-x86_64 directory. In fact, the
cpp directory contains many different versions of
xmogrt.dll, all built with different versions of the Microsoft C++ compiler. Feel free to contact us for advice regarding all the different versions.
You might also wish to take a look at the FAQ about weakly vs. strongly named assemblies.
In our default in-process mode, the application will need access to the underlying Java classes and a Java runtime environment. While the runtime is capable of finding and using an installed JRE, you might wish to install your own JRE as part of your application. This guarantees that your users don't have to download and install anything other than your application and that they are always using the correct version of Java. This approach is sometimes called "using a private JRE" and its only downside is the potentially significant increase in the size of your application's disk image, something that is less and less of an issue in the days of terabyte hard drives.
Our customers (and we) have achieved excellent results with the application layout shown in the image to the right. This layout is by no means "the required layout" or even "the best way to do it," but it has some nice characteristics. Assuming that your application can be deployed in one application folder, this layout is well organized and is totally self-contained. As a result, your integrated application is xcopy-deployable, i.e. it can be copied from one folder to another and it will still work without any reconfiguration.
The bin directory contains all the DLLs, .NET assemblies, and the co-located configuration file. The lib directory contains all required Java classes and properties files, usually packaged as jar files. The jre directory contains a Java runtime environment.
As long as you are using relative paths in the runtime configuration, your application will work anywhere without requiring changes to the configuration. The following snippet shows the explicit configuration code that would be used in your application to work with the above layout:
IJvmLoader loader = JvmLoader.GetJvmLoader(); loader.AppendToClassPath( @"..\lib" ); loader.AppendToClassPath( @"..\lib\myapi.jar" ); loader.AppendToClassPath( @"..\lib\myutil.jar" ); loader.JvmPath = @"..\jre\bin\server\jvm.dll";