Linux C# Mono for Display App

Linux C# Mono for Display App

Overview:

The Display app of the Windows version of my Exploratory Project (EP) is written in Microsoft Visual C# Express although, as it was completed, it doesn't really use the “Visual” part of the software since it obtains the controls/widgets to be displayed from the xml as part of the definition file of the ARINC-661 standard rather than placement via visual application techniques.

Early on I had done some internet searches for C# for Linux. These turned up Mono but only indicated downloads for Windows and other operating systems as well as Ubuntu and Debian. So it didn't seem like I could use it since I am using Fedora.

Therefore, I began this new phase to do the EP Display app by thinking I would need to redo the application in C and use GTK+ to display the window and its widgets. Therefore, I started on that course.

I rewrote my Ada version of an xml reader in C to be able to use it to read the definition file and started rewriting the C# class that reads the definition file and builds the contents of a C# configuration class that can be used to look up the characteristics of windows and widgets, their identifiers, and the like as found in the xml.

From this initial work on just one of the display app classes I could see it wasn't going to be a simple task. Therefore, I tried again to see if I could use Mono.

Results:

My first search again resulted in Ubuntu and Debian for downloads. But then, this time, adding Fedora to the search produced a question / answer sequence where the question was whether there was a way to use C# with Fedora. An answer was to use the command

su -c 'yum install monodevelop'

to download and install Mono for Fedora.

I did so and (after entering the root password that it requested) it did the download and then the install without further intervention. This resulted in a MonoDevelop application.

I opened the C# project file from Windows and tried a build. This resulted in an error

“Framework'.NETFramework 4.0 Client Profile' not installed.”

A web site gave that

MSBuild projects can reference arbitrary framework profiles (subsets), which will only work if the profile is installed in the runtime's frameworks definitions. Mono doesn't have all of the framework profiles that .NET has, e.g. the .NET 4.0 Client Profile.

To work around this, change the project to use the full 4.0 framework.
In MonoDevelop, here's how you change the setting:

1. Right click on project name
2. Options > Build > General > Target Framework
3. Select a framework that is installed on your computer.
   

So I selected Mono / .NET 3.5 and tried the build again.

This time I got

“Build failed. Could not find a part of the path

“/home/clayton/Source/EP/CDS/A661/Properties/Resources.resx””.

A path (Properties) and file (Resources.resx) that I hadn't copied from my Windows project.

Therefore I did so. This time the build resulted in an error for my SyncQueue.cs class that for the “using System.Collections.Concurrent;” statement that “Concurrent doesn't exist”. Therefore this is a .NET 4.0 C# class but not a .NET 3.5 class.

Therefore, I had to remove my use of the Concurrent class and use the System.Collections synchronized queue class. This means that I will need to rework the data that is queued so that it doesn't need the typed data queue that's available with the Concurrent class. The use of the typed queue was nice since I could have a variable in the typed structure that indicated the number of bytes in named pipe message that had been received from the user application and be able to obtain the number of bytes in the read from the queue.

However, when this change was made, the build succeeded. Therefore, I could start debugging. This produced the necessity of changing the configuration file, definition file, and log file paths to Linux rather than the Windows format that they had been in.

I also cloned the MS_Pipe class to a Named_Pipe class in preparation to changing it to use Linux named pipes for communication with the user application of the ARINC-661 protocol. This class had to be effectively disabled since attempting to execute the open between the Display app and the User app resulted in errors since Linux couldn't, of course, handle the interface to Windows MS_Pipe functions.

And that was that. Running the Mono application, with those few changes, resulted in the disabled xml specified window with the enabled widgets (labels, text boxes, radio buttons) displayed. All done in a day.

No need for me to convert to C, write GTK+ code, look up interfaces to use for the various widgets, etc, etc, etc. Hooray! Mono had the C# xml reader and other classes that I had been using along with classes to display widgets.

Next:

I now need to implement the C# named pipe class to interface with the user apps and be sure that the user app use of its Ada package works with the A661 protocol. In addition, I need to rework the write and read from the now synchronized queue for received A661 messages since the concurrent queue class is no longer available. Also there will be the change to launch the user apps identified in the configuration file.

On the downside, that's hardly enough to keep me busy for long. I'll have to look around for an actual application to implement using my Exploratory Project framework and methods.