Archive for April, 2008

Running DotNet application under 64-bit

Recently, someone asked me to help with getting an existing Dotnet application to run on 64-bit XP. It turned out to be pretty easy, compared to the transition from 16-bit to 32-bit in the old days.

Why would you run 64-bit?

Most of the modern processor these days are 64-bit CPU, but we still live in a mostly 32-bit world. One chief reason is that 64-bit drivers are not yet available. Application compatibility is less of an issue because 64-bit windows can run 32-bit application under WOW (windows on windows). When I do see people run 64-bit OS, it is usually because they are either diehard hobbist who want the latest and greatest or they are using application that requires a large amount of memory.

DotNet under 64-bit

  • Microsoft has 32-bit and 64-bit runtime for DotNet 2.0 or above. When you install the 64-bit runtime, the 32-bit runtime is also installed.
  • Dotnet assemblies compile into MSIL (Microsoft Intermediate Language). MSIL can run in 32-bit or 64-bit mode.
  • When you compile, you have the option to compile Any CPU, x86, x64 and Itanium. Remember that DotNet does not compile into machine specific code but into MSIL. This merely set a flag to tell DotNet which environment to run in.
  • If you set the flag to any cpu, it will run in 64-bit on 64-bit machine and 32-bit on 32-bit machines.
  • If you set the flag to x86 and run it on a 64-bit machine, it will run the program under WOW in 32-bit emulation mode.
  • If you set the flag to x64 and run it on a 32-bit machine, you will get an exception.
  • The only reason you want to set the flag is dependencies. If you reference 32-bit code within your application (such as unmanaged COM code), you will need to run the application under 32-bit mode.
  • Note that DotNet 1.1 or earlier are available only in 32-bit mode. If you reference DotNet 1.1 code, you will need to run it in 32-bit mode.



April 23, 2008 at 8:03 am 2 comments

Organizing NUnit Test in a .Net or MonoDevelop Solution

When I first use Nunit, I was confused on how to set up Nunit test inside a solution. I can think of several alternatives:

  1. Have Nunit test be in the same project / Assembly.
  2. Same as 1, but use a compiler flag like #ifdebug to filter out the Nunit code during production.
  3. Create a single test project where unit test for all solutions resides. So there is a single “Unit Test” project solution where all of the unit test are stored.
  4. For each project in the solution being tested, create a corresponding test project. So if you have a “Calculation” project, you would have a corresponding “Calculation Test” project that holds all of the unit test for Calculation Project.

Personally, I do not like option 1 because it deploys Nunit code into production. I do not like option 2 because preprocessor macros are error prone. In addition, if you are only testing when the debug flag is true, are you really testing the code?

I prefer option 4 over option 3 because it gives me the flexibility to organize the test and also promote isolation between different tests. If you lump all of the test under the same project, it may be difficult to figure out which test is from which project.

For example, if we want to do a Calculator application, you’ll end up with the following solution structure:

Calculator — Solution for the calculator application

CalculatorApplication — Startup project. Contains the main routine.

CalculatorClass — this is the class code for the calculator.

CalculatorClassTest — this is the unit test for the CalculatorClass.

For each project will have a corresponding unit test project. The unit test project will reference the assembly of the project being tested. The CalculatorApplication just enough code to call the other classes. It is not tested. It may be a pain to setup at first, but it is the most organized and flexible way to organized your unit test.

April 14, 2008 at 9:18 pm Leave a comment

Using Subversion source control with MonoDevelop

This article describes how to integrate Subversion source control with MonoDevelop. Subversion has several methods of accessing a repository. In this example, we will be using accessing the repository directly through the local file system. This means the repository sits on the local machine you are working on.


The following software must be installed.

  • MonoDevelop
  • Subversion

Creating a Subversion Repository

First we need to create a repository where we will store our source code. There appears to be no way to create the repository within MonoDevelop, so you will need to run this from the command line (replace <myhomedirectory> with your home directory.

svnadmin create <myhomedirectory>/subversion

This creates a repository “subversion” in your home directory (note: the default file system is FSFS).

Adding the solution to the repository

Once the repository is created, We can add the solution to the repository.

  1. Launch MonoDevelop.
  2. Open the solution.
  3. In the solution View, right-click on the solution and select Version Control->Publish. This brings up the select repository dialog box.
  4. Click on the “Registered Repositories” tab.
  5. Click on the add button.
  6. Enter the name of the Repository such as “subversion”.
  7. Set the protocol to “File”.
  8. Set the URL to file:///<myhomedirectory>/subversion.
  9. Press OK. This closes the Add repository.
  10. Select the repository and press OK. You will be asked if you want to publish the project into the repository.
  11. Answer Yes.

The solution is now added to the repository.

Using the source control

Now that the solutions has been added to the repository, all of the source files are now under source control. Right-click on any of the file and select Version Control. You can now update, diff, or revert file changes.

April 12, 2008 at 10:33 pm 8 comments

Installing MonoDevelop 1.0 on Suse 10.3

MonoDevelop 1.0 has finally been release on March 14, 2008. I figured that I’ll install the MonoDevelop since I like an IDE that will do stuff like autocomplete and because Yast should also include all of the dependent components.

I have heard of numerous problems with installing MonoDevelop on linux distros because a package were not available. I was expecting Novell to make certain that MonoDevelop would install smoothly on Suse 10.3. While installation were far easier on Suse than on other distros, it still was not trouble-free.

The following are instructions on how to install MonoDevelop 1.0 on Suse 10.3. Note that I was installing on a virtual machine, but installation for a real machine should be exactly the same.

Adding the Mono Repository

The first step is to add the Mono distro to Yast, so that the package will appear in the package selector.

  1. In Suse 10.3, launch Yast. You will be prompted to enter the root password. Enter the password and press OK.
  2. Click on Software Repositories in Yast. Click on the Add button. Select the option “Specify URL” and press Next. Enter the name of the repository of “Mono Repository” and the URL to “; and the press Next.
  3. Press Finish. You will be prompted to sign with untrusted public key. Press Trust and Import key. The Software Repository window will close.

Installing MonoDevelop

Now that the Mono repository has been added to Yast, we can install the MonoDevelop package. This is where the troubles begin. Gnome and Banshee both use an older version of Mono library that was installed by default by Suse. When you attempt to install a new version of Mono, Yast doesn’t like it because you are changing the packages that Gnome and Banshee depend on. The trick is to tell Yast to ignore the dependencies since the library should be backwards compatible (“should” but who knows).

  1. Click on the Software Management in Yast. This brings up package selector.Yast Package Selector
  2. Type “monodevelop” in the search. This brings up MonoDevelop on the left pane.
  3. Select Monodevelop and press Install. This move MonoDevelop to the right pane.
  4. Press the Accept button. A change summary window will displaying dependencies.
  5. Press the Confirm button. A resolve window appears, it will warned you that mono-nunit cannot be installed due to missing dependencies. The problem is that mono-nunit wants a later version of mono-core than the one installed by default by Suse 10.3.Monodevelop first resolve
  6. Click on “Install mono-core although it would change the vendor” and press confirm. You are changing vendors because you are now getting it from the instead of Novell. Now another resolve window pops up. This time it warns that gnome_multimedia, banshee-engine-gst, banshee, banshee-plugins-default, and banshee-plugins-DAAP has missing dependencies. This is because Banshee and gnome-multimedia uses mono-core and you are installing a new version of mono-core.
  7. Select “Ignore this requirement just here” for each conflict and press Confirm. Selecting the other option and you may find Banshee deleted!

Unfortunately, we are not home free, when I launch MonoDevelop and create a new project, I get the following error:

Exception occurred: Exception has been thrown by the target of an invocation.

System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. —> System.TypeInitializationException: An exception was thrown by the type initializer for MonoDevelop.SourceEditor.Gui.SourceEditorDisplayBinding —> System.DllNotFoundException:
at (wrapper managed-to-native) GtkSourceView.SourceTagTable:gtk_source_tag_table_get_type ()
at GtkSourceView.SourceTagTable.get_GType () [0x00000]
at GtkSharp.GtksourceviewSharp.ObjectManager.Initialize () [0x00000]
at GtkSourceView.GtkSourceViewManager.Init () [0x00000]
at MonoDevelop.SourceEditor.Gui.SourceEditorDisplayBinding..cctor () [0x00000] — End of inner exception stack trace —

at (wrapper managed-to-native) System.Reflection.MonoCMethod:InternalInvoke (object,object[])
at System.Reflection.MonoCMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000] — End of inner exception stack trace —

at System.Reflection.MonoCMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000]
at System.Reflection.MonoCMethod.Invoke (BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000]
at System.Reflection.ConstructorInfo.Invoke (System.Object[] parameters) [0x00000]
at System.Activator.CreateInstance (System.Type type, Boolean nonPublic) [0x00000]
at System.Activator.CreateInstance (System.Type type) [0x00000]
at Mono.Addins.TypeExtensionNode.CreateInstance () [0x00000]
at Mono.Addins.InstanceExtensionNode.GetInstance () [0x00000]
at MonoDevelop.Ide.Codons.DisplayBindingCodon.get_DisplayBinding () [0x00000]
at MonoDevelop.Ide.Gui.DisplayBindingService.GetCodonPerFileName (System.String filename) [0x00000]
at MonoDevelop.Ide.Gui.DisplayBindingService.GetBindingPerFileName (System.String filename) [0x00000]
at MonoDevelop.Ide.Gui.Workbench.RealOpenFile (System.Object openFileInfo) [0x00000]
at MonoDevelop.Ide.Gui.Workbench.OpenDocument (System.String fileName, Int32 line, Int32 column, Boolean bringToFront, System.String encoding, IDisplayBinding binding) [0x00000]
at MonoDevelop.Ide.Gui.Workbench.OpenDocument (System.String fileName, Int32 line, Int32 column, Boolean bringToFront) [0x00000]
at MonoDevelop.Ide.Gui.Workbench.OpenDocument (System.String fileName, Boolean bringToFront) [0x00000]
at MonoDevelop.Ide.Gui.Workbench.OpenDocument (System.String fileName) [0x00000]
at MonoDevelop.Ide.Templates.OpenFileAction.Run (MonoDevelop.Projects.ProjectCreateInformation projectCreateInformation) [0x00000]
at MonoDevelop.Ide.Templates.ProjectTemplate.OpenCreatedCombine () [0x00000]
at MonoDevelop.Ide.Gui.Dialogs.NewProjectDialog.OpenEvent (System.Object sender, System.EventArgs e) [0x00000]
at GLib.Signal.voidObjectCallback (IntPtr handle, IntPtr gch) [0x00000]

Fixing the dependency issue

A quick search through the google reveal this bug. What seemed to be happening is that an exception is thrown when MonoDevelop attempts to display your code using gtksourceview. Apparently, gtksourceview-2.0.0-5 can not be use in place of gtksourceview18-1.8.5-16. To fix this, do the following:

  1. Make sure you have the Suse Disc in the drive, since gtksourceview18 is on the disc. Launch Yast.
  2. Click on Software Management. This launches the Package Selector.
  3. Type in gtksourceview18.
  4. Select gtksourceview18 and press Install, and then accept.
  5. Click confirm on Change summary window.
  6. When prompted to install or remove more packages, press No.

With gtksourceview18 installed, Monodevelop seems to work now. Banshee still seems to work just fine. Hopefully, the next version of MonoDevelop will be less painful to install.

Problems with Help

When I select Help, I get the following error: “The help window can’t be shown. Monodoc v1.2.3 is not installed or could not be found.”. Apparently, Monodoc is not installed and it wasn’t obvious which package in Yast it was. After some experimentation, I discovered it was the package mono-tools.

  1. Launch Yast and select Software Management.
  2. Type in mono-tools in the search, select mono-tools and click install.

Additional Problems

Unfortunately, there are additional problems that still needs to be resolved:

  • When I toggle the bookmark on my editor, I get the following exception:exception occurred:

    at (wrapper managed-to-native) MonoDevelop.SourceEditor.Gui.SourceEditorBuffer:g_slist_free (intptr)
    at MonoDevelop.SourceEditor.Gui.SourceEditorBuffer.ToggleMark (Int32 linenum, SourceMarkerType type) [0x00000]
    at MonoDevelop.SourceEditor.Gui.SourceEditorBuffer.ToggleBookmark (Int32 linenum) [0x00000]
    at MonoDevelop.SourceEditor.Gui.SourceEditorView.OnButtonPressEvent (Gdk.EventButton e) [0x00000]
    at Gtk.Widget.buttonpressevent_cb (IntPtr widget, IntPtr evnt) [0x00000]

April 5, 2008 at 11:24 pm 11 comments


April 2008
« Feb   May »

Posts by Month

Posts by Category