Variant
model developers will link to and extend the OSM software library
‘OSM.CommonModels.dll’ in order to build a custom variant model in a separate DLL. The
OSM.CommonModels.dll exposes a number of object interfaces to allow direct control of
OSM simulations from third-party applications. Because variant models implement
these same interfaces, third-party applications can be built to work with any
variant OSM model, or can be built to work specifically with the custom variant
DLL.
Also see:
By directly
linking to OSM DLLs, third-party applications can provide an extremely rich
user experience and improved performance. The graphical user interface may
provide means to build and execute OSM command logic without having to build
command files. Alternate reports and graphics can be created on the fly by the
third-party application. The entire OSM runtime can be re-envisioned.
This level
of integration does have costs. It requires the third-party application to be
compiled with base or variant DLLs, which may introduce versioning issues.
Moderate to advanced programing experience plus familiarity with the OSM object
model is also required when designing these applications.
Microsoft’s
Visual Studio 2012 is the recommended development environment for building an
application that links directly with OSM libraries. Either VB.Net or C#.Net can
be used to work with the OSM API (application interface). OSM libraries can be
controlled though Python using .Net extensions or by using Iron Python.
OSM is
built entirely with Microsoft’s .NET Framework with managed memory, so linking
these DLLs directly with COM based applications (e.g.,
C, C++, Delphi, R), which primarily use unmanaged memory, is not
straightforward. For these situations, it may be easier to design an R script
or C++ application that interacts with the OSM executable through command
files.