...
How to port the OpenMI environment from Windows to Linux
Table of contents
| Table of Contents |
|---|
1. Introduction
The document describes how to generate and run Linux dlls and executables from the original Windows C# sources. This is done by using Mono, a .NET Open Source project on different platforms. Only few adjustments are necessary in order to port the complete OpenMI functionality:
- the standard OpenMI.Standard
- the source development kit Oatc.OpenMI.Sdk.*
- the dlls and executables Oatc.OpenMI.Gui.* for running OpenMI in the configuration editor with GUIs or from command line.
2. Technical prerequisites
2.1. Machine and OS of the test system
- workstation with an Intel Xeon processor
- 64bit openSUSE 11.0
2.2. Mono
- Mono v. 1.9.1. for openSUSE 11.0 in 64 bit mode. V. 1.9.1. is also referred to as Mono 2.0.
- The standard and the sdk sources should be compilable with previous versions. But the GUIs require Windows.Forms, which has been shipped with v. 1.9.1. in Oct. 2009.
2. How to compile and execute a Mono application
Command for generating a dll:
| Panelcode | ||||
|---|---|---|---|---|
| ||||
|
gmcs -target:library -out:<target>.dll -r<linkedLib_1>.dll,<linkedLib_k>.dll -pkg:<package_1>.pc;...;<package_m>.pc <source_1>.cs <source_n>.cs -r:<linkedLib_?>. pc are linked shared libraries (path and name)dll : reference to linked shared libraries (path and name) -pkg:<package_?>.pc are: ASCII files (path and name), that refer to linked shared libraries <linkedlib_?>.dll. They contain the path and the version of the dll. Example for the Windows .Forms dll: prefix=/net/themis2/system/akprog/CS/OATC/AthenTraining/xe64/src/OpenMI.Standard: prefix=/usr/lib/mono/2.0
WindowsForms
Windows Forms
2.0
-r:${libdir}/System.Windows.Forms.dll |
Used command Command for generating an exe file:
| Panel | ||||
|---|---|---|---|---|
| ||||
gmcs | ||||
| Code Block | ||||
| java | java |
gmcs -out:<target>.exe -r<linkedLib_1>.dll,<linkedLib_k>.dll -pkg:<package_1>.pc;...;<package_m>.pc <source_1>.cs <source_n>.cs |
Further compile information for resources is given in section 3.3..
Applications compiled with Mono do not run directly on the linux system, they are interpreted on a runtime engine, comparable to the virtual machine in java. Thus, the command in the terminal window command line has to start with mono, e.g.:
| Panel | ||||
|---|---|---|---|---|
| ||||
mono Oatc.OpenMI.GUI.ConfigurationEditor. |
...
exe |
3. How to port C# sources of ...
3.1. ... the standard OpenMI.Standard.dll 1.4.0
The original source code can be compiled without any changes.
3.2. ... the sdk Oatc.OpenMI.Sdk.*.dll 1.4.1
The original source code can be compiled without any changes.
3.3. ... the GUIs Oatc.OpenMI.Gui.*.dll 1.4.1
The GUI sources use Windows.Forms, that works with resource files in order to design the graphical elements. The Windows resource files (*.resx) are generated automatically in the Microsoft Visual Studio IDE. Linux applications do not process them and create a "resource not found" exception during runtime. Thus, the resources have to be converted with the Mono tool resgen / resgen2. The following command generates a Linux readable resource <name>.resource:
resgen <name>.resx generates a Linux readable resource <name>.resource .
Visual Studio assigns a resource file to a C# file occurs automatically. On a linux machine naming conventions guarantee the correct assignment. On linux systems C# and resource file must have the same prefix. This first part of the prefix must be the namespace. Example for ElementSetViewer in the namespace Oatc.OpenMI.Gui.Controls:
• Oatc.OpenMI.Gui.Controls.ElementSetViewer.cs
• Oatc.OpenMI.Gui.Controls.ElementSetViewer.resources
Not all resources can be processed by Mono. Mono 2.0 has nearly the full functionality of Windows.Forms. It does not support the WindowsPresentationFoundation WPF, shipped since .NET 3.0, which generates resources in XAML style or logical resources. Thus, it is highly recommended to leave out any WPF elements in future OpenMI GUIs.
Mono uses the same error message as Windows. You look them up on the MSDN homepage.
Resources: The original Windows resources contained *.bmp graphics with a 24bit colour depth. Linux could not process them. The solution was to convert the BMPs externally to 8bit GIFs, before adding them to the resource in the Visual Studio IDE.
3.3.1. CommandLine
no changes
3.3.2. ConfigurationEditor
• Individual cursors (Source, Target) can't be displayed, but connecting models works
• ConnectionDialog:
todo:
"Apply" a connection
-> runtime error
listLinks.SelectedIndex = selectedIndex; // = -2;
3.3.3. Control
• ExchangeItemSelector
Filters for ElementSet and Dimension
Collapse of treeViews
3.3.4. Core
no changes
...
4. Migration - step by step
The best strategy when migrating a model is to split the process into a number of steps; at the end of each step you can compile your code and run a small test.
The steps needed for migration are described in this chapter.
...
5. Migration of the Simple River
The previous chapter described the steps involved in migrating a model to the OpenMI.
This chapter shows how the migrated code is developed for the Simple River example.
5.1 The Simple River Wrapper
...
Fig. 13 Simple River wrapper classes
...
6. Testing the component
It is important to test the component to check that it is working correctly. Traditionally, the procedure has been to complete implementation and then run the engine to see if it produces the correct results. However, in recent years new methodologies have been developed for testing. The dominant testing method for object oriented programs is unit testing. Unit testing is done in parallel with the implementation. This means that you will be able to find errors earlier and thus save time on debugging your code later.
This chapter discusses the testing of migrated components.
...