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:

File Description
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.

A file layout that lends itself to xcopy-deployable applicationsOur 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";

Copyright 2006-2011 by Codemesh, Inc., ALL RIGHTS RESERVED

frequently asked questions
home products support customers partners newsroom about us contact us