# Linking OSM to another Application

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:

Linking with R

OSM source code documentation

## Advantages

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.

## Disadvantages

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.

## Development environment

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.