Getting Started in Linux for the Experienced .NET Developer (Comments)

Here are my comments on the SYS-CON FRANCE article titled "Getting Started in Linux for the Experienced .NET Developer" (http://fr.sys-con.com/read/143299.htm)

Our company is in the process of porting a large .NET application to OS X and Linux using Mono. I’m constantly impressed with how mature the mono platform is, but as you state there is still some work to be done in the WinForms area. For us, the primary goal is to maintain a core code base which is exactly the same on all platforms (Windows, Mac OS X, and Linux) and then to have one or more platform specific assemblies which contain P/Invoke statements, etc. for each disparate OS.

I’m glad to see that the Mono team is building the new WinForms DLL on the System.Drawing namespace. In our application, which is a GUI application, we have implemented all of our own controls (buttons, tabs, grids, etc.) based on the System.Drawing namespace. It’s not as difficult as it may sound and it allows us to deal with cross platform issues directly.

I’m sure I speak for millions of Visual Studio.NET developers when I say that I long for the day when I can compile any purely .NET GUI application within Visual Studio and then simply xcopy it to OS X or Linux and see it run without issue.

If you are a Windows developer and are curious about Linux let me recommend SUSE Linux 10.0. We ALL need to support Novell in any way we can if for no other reason than they started and support the Mono project. Not to mention SUSE Linux 10.0 is arguably the best desktop Linux distribution available.

One thing I can’t understand is why the Apple people have not jumped on the .NET bandwagon. Don’t they realize that 76% (very conservative estimate, e-week) of the world’s developers are Visual Studio developers? Most software companies write there software first for Windows (90% market share) and then worry about OS X and Linux in “the next version”. Don’t you think that if it were a viable option we would release Windows, Mac OS X, and Linux versions all at the same time?

Novell, I love you!

Apple, how about spending some research dollars to support .NET on OS X?

Hot news for .NET developers wanting to test mono on Linux

Here is a valuable article for anyone wanting to try mono on Linux:

exerpt from "Getting Started in Linux for the Experienced .NET Developer"
...
There is a Live Linux CD specifically for Mono users. The Monoppix live CD (http://www.monoppix.com/) can be freely downloaded. This is a painless way to test-drive both Linux and Mono without having to build a PC for it.
...

Full article available here.
http://fr.sys-con.com/read/143299.htm

A better way to output debug information (OS X to Windows XP)

I did some snooping into my UDP problem on OS X and found that the problem was not MONO, my code, or OS X, but rather the fact that the Windows XP firewall was turned on preventing the machine I was sending packets to from receiving them. Now I’m sure I’ve turned this off more that once. At any rate, UDP communication between Mac OS X and Windows XP seems to work fine using MONO.

My plan at present is to send all debug output from my MONO .NET application running on OS X to a Windows box using UDP (udpclient class). I then receive the UDP traffic on the Windows XP box using a .NET service and debug out the information.

Ultimately I view the WindowsDebugOutput using DebugView a freeware program from SysInternals (http://www.sysinternals.com/utilities/debugview.html)

This whole process may seem convoluted, but it is also reliable and I’m going to need to debug out a lot of information if I’m going to successfully get this application moved from Windows to Mac.

So far the only problem I’ve encountered with MONO is that using the TextBox control causes my application to crash. All-in-all the MONO team has done a great job.

-d

Prerequisites for WinForms development on OS X

As with most large-scale applications, the application I’m attempting to move to OS X is comprised of many individual DLLs. This architecture should be a benefit to me as I will be able to isolate and certify each individual DLL on OS X before attempting to run the entire program.

I started by creating a test harness for the simplest DLL within my application which contains my standard exception handler, event logging, and other low-level utilities. This DLL is also used by all other DLLs within my system.

The first problem I encountered was how to capture debug information so I can figure out what is going on under the covers. Since I’m doing all WinForms development I don’t have the benefit of a terminal to debug out information to. There may be a debug output viewer available for OS X, but I’m not aware of one. My solution was to use the standard .NET/Mono debug out statement and implement a custom trace listener.

Creating a custom trace listener in .NET is a piece of cake as shown below:

//BEGIN CLASS CODE

public class DebugOutput : System.Diagnostics.TraceListener
{
public DebugOutput()
{

}

public delegate void outputDebugString(string Text);
public event outputDebugString OutputDebugString;

public override void Write(string info)
{
try
{
OutputDebugString(info);
}
catch (System.Exception ex)
{
MessageBox.Show(ex.ToString());
}
}

public override void WriteLine(string info)
{
try
{
OutputDebugString(info);
}
catch (System.Exception ex)
{
MessageBox.Show(ex.ToString());
}
}
}

//END CLASS CODE

The next step was to use the custom trace listener in my test harness.

Step 1: Create the event handler.
private void OutputDebugString(string Text)
{
try
{
lblDebugOutput.Text = lblDebugOutput.Text +
"NEW STATEMENT:" +
System.Environment.NewLine + Text + System.Environment.NewLine + System.Environment.NewLine;
}
catch (System.Exception ex)
{
MessageBox.Show(ex.ToString());
}
}

Step 2: Initialize the custom trace listener and the event handler.
private DebugOutput m_objDebugOutput = null;

private void frmTestHarness_Load(object sender, System.EventArgs e)
{
m_objDebugOutput = new DebugOutput();
m_objDebugOutput.OutputDebugString += new
DebugOutput.outputDebugString(OutputDebugString);
System.Diagnostics.Debug.Listeners.Add(m_objDebugOutput);
}



Now I’m able to use debug statements within my application and see them on screen.

VERY IMPORTANT: When I started this, I attempted to use a TextBox to display the debug output. For some reason, the act of setting text in my TextBox caused my application to immediately crash. Next I tried to send UPD packets to another computer as an alternate way of viewing debug output. This also didn’t work for me. Finally I ended up using a Label. A Label works fine, but I’m going to need to go back later and figure out what the problem is with TextBoxe controls and the UDP client as both of these are used within my application.

I’m now in the process of verifying that all functions act exactly the same way on both Win32 and OS X.

More to come.

-d

Getting Started with Mono on Mac OS X

Mono is an amazing technology which promises to allow .NET System.Windows.Forms applications to run unchanged on all supported version of Windows and also Mac OS X and Linux. I’ve been a Windows developer for years and am intrigued by the prospect of writing real-world applications that will run equally well on all of these platforms.

I’m going to start by migrating a large retail application written in C# to Mac OS X. I’m going to do my best to maintain the same code base for all platforms. If the migration from Windows to Mac is successful, then I’ll move on to Linux.

Today I was able to get a hello world style WinForms application running on OS X (originally complied on Windows XP).

I started by downloading and installing the latest version of Mono from the following URL:

http://www.mono-project.com/Downloads

Next I used the following getting started guide to get my application running.

http://oepapel.blogspot.com/2005/04/windowsforms-and-mac-osx.html

for me the macpack program was a real lifesaver in getting my application up and running. More information on this utility can be found at the following URL:

http://www.joeysmith.com/cgi-bin/man/man2html?macpack+1

I can’t wait to see what tomorrow has in store.

-d