I've been using MonoDevelop on Ubuntu this weekend, because it just doesn't feel right to use it on Windows. If you have Windows and need to write C# code, I'm sorry you're going to use Visual Studio, period.

Sun VirtualBox (VBox) has been instrumental in getting a Mono environment setup. VBox just rocks, but I did have one hickup. Initially I started with Suse Linux 11.2 because that's officially supported by MonoDevelop, but it kept throwing segmentation faults on bootup when trying to load the NIC driver. I tried several reinstalls, 32 bit, 64 bit, KDE, Gnome, different NICs inside VBox; nothing worked, so I gave up and went back to my tried and true friend Ubuntu. I never did figure out the root cause.

Instead of compiling MonoDevelop from SVN or from the latest release tarballs (like I did last time) I just grabbed the latest and gratest version of MonoDevelop (v 2.0) out of the multiverse, which to my surprise is pretty new. This took a LOT less effort and was much more stable.

I was actually able to make some changes to my command line library and for the most part get the tests to pass in Linux/Mono. The SVN integration worked perfectly. The MonoDevelop usability was pretty good. No hard crashes. No super strange compilation errors, everything pretty much worked right out of the gates.

I did have a few issues:

• Rename method or property fails and shows an exception dialog.
• Adding a NUnit test class automatically references the NUnit.Core and NUnit.Framework Mono package - which causes a compilation error: Duplicate TestFixture attributes. Removing the auto added NUnit package references fixes this, but this was less than obvious.
• Find Usages works most of the time, but also displays the declaration in the results.
• Go to declaration doesn't always appear on a method.
• No (obvious) way to interactively debug an NUnit test. Maybe there's a way to do this, but the only way I could find was to create a console app which runs an NUnit suite.
• The syntax highlighting is pretty monotone (at least the default scheme)
• The ability to automatically add a using statement when a used type isn't imported would be super handy. I've been using Re# far too long to NOT have this.

I will continue to use MonoDevelop, because its good enough and runs on Linux. Clearly it has a ways to go to compete with Visual Studio on Windows or many other Java or Ruby IDEs, but if you need to write C# code on Linux it'll certainly do. I'm hopeful the development experience with MonoDevelop will only get better in 2010.

This is a follow up to a previous post where I declared my laptop free of Vista. So to finally answer your question Ryan, its going well.

I've been running Ubuntu Intrepid (8.10) for the past 6 weeks almost every day and haven't had any problems. On the contrary, my laptop is super speedy now, and for whatever reason I swear the wireless works better and faster than it ever did with Vista.

I haven't missed MS Office all that much. I primarily use Outlook in MS Office anyway, and that's not by choice, so like most everyone I use GMail when not at work. When I do need to write an actual document I've found OpenOffice and Google docs more than adequate for my meager needs. In fact Google docs has actually been preferable since some of the docs I've needed to share authorship. I will have to concede that the UI in OpenOffice leaves room for improvement. The icons are hard to see and distinguish from their standard MS Office counter parts.

I've been using Gimp for image editing because it comes preinstalled, but its a little too technical for my needs, and thus difficult to do simple things. Even Photoshop is easier to use IMO. I find Paint.Net superior for my needs so I plan on switching since it will run on Mono. In fact a lot of the winform compatibility testing for Mono has been done using Paint.NET.

I have missed Visual Studio a little, but really what I miss are my ReSharper keyboard shortcuts. I've been primarily using Eclipse since I have been primarily doing Java and Groovy programming in my laptop. Both of these dev environments were quite easy to setup, especially the Android plugin for Eclipse, it works really quite well for editing and debugging. The Grails integration into Eclipse is pretty rough, so I'm looking into buying IntelliJ IDEA since I hear it has really good Grails support.  That and I'm already familiar with the keyboard shortcuts from ReSharper. I use the IDEA shortcuts in Re# which always throws my co-workers off when they try to pair with me.

The command line has been a little tricky to get used to, but has been more consistent between commands than Windows. And the translucent terminal windows are sure purdy. Ray pointed me to a free Ubuntu pocket guide that has helped smooth things over. I now often find myself incorrectly trying to use *nix commands in my DOS prompts at work. Perhaps its time to install Cygwin to iron it the discrepancy?

Not everything has been booz and cigars though. I've had serious issues with Mono, specifically MonoDevelop. The problems of course are my own making. The version of Mono and MonoDevelop packaged with Intrepid isn't quite as new as I would like, so I decided to build my own from the SVN trunk.  That was about 4 weeks ago.  After installing and bulding another 20 prerequisite libraries I finally got MonoDevelop to not only compile and load without crashing, but I also got it to compile and run my first C# app MonoDevelop!

This one goal of getting the latest version of MonoDevelop and Mono running on my Ubuntu box has taught me more about Mono and Linux than anything else I've done.  Despite the hair pulling its been a rewarding journey. I feel like I've earned my first Linux merit badge.

See Dylan, I gots its werking without resorting to a VM and the package manager!

Because I keep forgetting, and writing is supposed to help you remember things...

./etc$ sudo gedit environment

Today I start platform rehab, and this time I'm serious about getting clean. I'm writing this blog post from my laptop, yes my laptop, running Ubuntu 8.10. You don't get serious about dumping Windows until you take the plunge of installing Linux on your laptop. If you're like me, your laptop is your primary development box.

To my surprise, even my el-cheap-o laptop was absolutely painless to install Linux on. I suspect that maybe, just maybe, that even my 65 year old mom could do it. Even the wireless works connecting to the commuter trains free wifi. The only slightly difficult part was setting up my development environment, and that was mostly because I'm not super familiar with the OS or tooling, all of which are my problems.

Why did I switch? To people who use Linux already this is a rhetorical question, but for me the reason was pretty simple: Linux is free and good. I generally don't play games anymore, especially on my laptop. I don't really use MS Office too much, and Open Office is more than OK for my needs. Firefox is just as good on Linux as Windows.

More importantly though, Linux is the gateway to the backbone of the Internet. You don't build a web company on a proprietary per license platform when you have equivalent or better alternatives for free; after all Microsoft is dead. This speaks directly to competitive advantage and more importantly to a company's bottom line. I'm cheap. Startups, if their going to be successful, should be cheap.

Now back to GRails for me.

Don't include Windows.h -  I had to say it.  ;)

Always have a blank line at the bottom of each source or header file.  You get g++ compiler warnings if files don't have an extra carriage return at the bottom.

Compiler pragma warning disable statements should be ifdef'd for WIN32 only.

#include statements must match the case of the header file name.

#include "gpireader.h" // won't compile on g++, but

#include "GPIReader.h" // will compile on g++

 

Don't forget to use virtual destructors where appropriate, g++ will complain if they're missing.

Don't memset STL strings (std::string) to zeros.  Strange and odd memory corruption will occur if you do.

Don't memset structs which contain STL strings, see point above.

Don't include enum names. 

if (res == ResourceType::AccessBlock) // won't compile on g++, but

if (res == AccessBlock) // will compile on g++

 

Don't include the class prefix in header files for method declarations.

std::string GPIReader::GetXMLStringResource(ResourceType type);  // won't compile on g++, but

std::string GetXMLStringResource(ResourceType type); // will compile on g++

 

stricmp (case insensitive strcmp) function is not available on Linux, you must toUpper then compare or something.

Being the only one at work with any Linux experience, I was elected by default to port our C++ API over to Linux.  Luckily we had some CxxTests already being utilized on Windows, and good thing we did because as I found out, just getting our API to compile on Linux didn't mean it would run on Linux.  These unit tests saved me around 2 days of work (it only took me about 12 hours to port).

The Linux environment I chose to use was Ubuntu running Eclipse CDT.  After some Googling I found that there's an Eclipse plugin for CxxTest that is similar to the Eclipse JUnit runner.  That sounded very appealing; I sure wish there was Visual Studio CxxTest runner.  Unfortunately all of the instructions for the plugin are about getting it to work with Windows and Cygwin, which wasn't much help in my scenario.  To get the pluging to work I found I needed to:

1. Install the BFD dev library onto my Ubuntu system using apt-get.
2. Remove the -libintl flag from the test project's additional libraries section.

After making those changes I was able to get the CxxTest runner building and running just fine.  The one thing I did notice is that the tests run only after 2 rebuilds of the test project.  I'm not sure why that is, or if I was doing something wrong - it was getting annoying having to edit my test file, compile, edit it again, and then recompile a second time to get the tests to run.  There must be a manual way to force the tests to build...

Hooray!  I now have both of my LCD's working in Ubuntu, ala "TwinView."  I attemped to use the nVidia confiuration utility, but ended up needing to manually edit my xorg.conf file to get the right settings.  I think the utility would have worked if my secondary LCD was connected using a DVI cable, but unfortunately it only supports VGA so I think the resolutions were not getting auto-detected properly.

For future reference, here's the relevant portions of my xorg.conf file with the dual monitor stuff in bold:

Section "Monitor"
    Identifier     "Acer AL2216W"
    HorizSync       30.0 - 82.0
    VertRefresh     56.0 - 76.0
    ModeLine       "1680x1050" 146.2 1680 1784 1960 2240 1050 1053 1059 1089 +hsync -vsync
    Option         "DPMS"
EndSection

Section "Device"
    Identifier     "nVidia GeForce 8600 GT"
    Driver         "nvidia"
EndSection

Section "Screen"
    Identifier     "Default Screen"
    Device         "nVidia GeForce 8600 GT"
    Monitor        "Acer AL2216W"
    DefaultDepth    16
    Option         "UseFBDev" "true"
    Option         "RenderAccel" "true"
    Option         "TwinView"
    Option         "MetaModes" "1280x1024, 1680x1050; 1024x768, 1280x1024"
    Option         "TwinViewOrientation" "LeftOf"
    SubSection     "Display"
        Depth       16
        Modes      "1680x1050" "1280x1024" "1280x960" "1280x800" "1152x864" "1024x768" "800x600" "640x480"
    EndSubSection
    SubSection     "Display"
        Depth       24
        Modes      "1680x1050" "1280x1024" "1280x960" "1280x800" "1152x864" "1024x768" "800x600" "640x480"
    EndSubSection
EndSection

I finally got 1680x1050 resolution working on my GeForce 8600 GT and Acer 22" widescreen LCD.  I used the Wubi installer for this which made it super easy to dual boot with Vista, however on the login screen I kept getting an "Out of Range" error using the built in OSS nVidia (nv) drivers.  After some reading I found that I would need the nVidia provided binary drivers to get dual monitors working anway, so I thought I would see if this would allow me to run at the native resolution of my monitor.  Of course I found that my particular video card, GeForce 8600 GT, was not supported by the nVidia binary driver installer.  I ended up doing a manual install of the drivers which actually worked, unlike the untold number of xorg.conf edits I made previously.

1. Download the NVidia binary drivers from their website.
2. Change to command line (CTRL ALT F2), and shutdown your display manager: sudo /etc/init.d/gdm stop
   
3. Install the dev libc libraries since no precompiled libs exist for my Ubuntu version.  sudo apt-get install libc-dev.
4. Install the drivers: sudo sh NVIDIA* -k (run this from the location you downloaded the binary drivers too).
5. Follow the install instructions, when prompted allow the installer to configure your xorg.conf file.