Matt Ward : Mono

NuGet Addin for MonoDevelop

MattWard — Mon, 07 Jan 2013 18:41:00 GMT

It has been a while since NuGet support was added to SharpDevelop so, after David Fowler announced that he had got NuGet building under Mono, I had a look at porting the SharpDevelop addin over to MonoDevelop and created a NuGet addin for MonoDevelop.

The addin provides a Manage Packages dialog that you can use to add, remove and update NuGet packages in a similar way to Visual Studio or SharpDevelop. Here is a screenshot of the Manage Packages dialog open in MonoDevelop running on OpenSuse 12.2

The addin has been tested with the following:

MonoDevelop 3.0.5
Mono 2.10.9
OpenSuse 12.2
Windows 7

The addin uses a slightly customised version of NuGet.Core based on the original NuGet's source code available from the mono-build branch. The source code for this customised NuGet.Core is available on GitHub.

Getting the Addin

The addin's source code is available on GitHub.

The addin is also provided as a pre-compiled binary available to download from a custom MonoDevelop repository:

http://mrward.github.com/monodevelop-nuget-addin-repository/3.0.5/main.mrep

You can add this repository to MonoDevelop via the Add-in Manager.

Please note that the addin is a beta release and more work is still to be done.

Manage Packages Dialog

The Manage Packages Dialog can be opened from the Projects menu by selecting Manage NuGet Packages.

It can also be opened by selecting the Solution window, right clicking either the solution, the project or the project's references and selecting Manage NuGet Packages.

As a NuGet package is installed or uninstalled you can see the package operations that executed by expanding the Messages section near the bottom of the dialog.

Configuring Package Sources

NuGet Package Sources can be configured in MonoDevelop's options.

In Linux you can open the options dialog by selecting Preferences from the Edit menu. In Windows you can select Options from the Tools menu. In the Options dialog scroll down the categories on the left hand side until you find NuGet and then select Package Sources. Here you can add and remove NuGet package sources.

PowerShell

Any PowerShell scripts in a NuGet package will be ignored by the addin since Mono does not currently have support for them.

There have been some attempts to implement PowerShell on Mono starting with Igor Moochnick who created Pash in 2008. Work on this was picked up launchpad.net by Jonathan Ben-Joseph but that work stopped. The latest effort on bringing PowerShell to Mono is Jay Bazuzi with recent work done on the Pash source code available on GitHub.

There was also some discussion in the NuGet forums on allowing some way of being able to write a .NET version of the PowerShell scripts (install.ps1, uninstall.ps1 and init.ps1).

Testing with .NET 1.1 in SharpDevelop 2.1

MattWard — Thu, 14 Dec 2006 21:12:00 GMT

SharpDevelop 2.1, as of revision 2135, now allows you to run your unit tests against .NET 1.1 or .NET 2.0.

Which framework your tests are run under is determined by the target framework your test project. So if you choose .NET 1.1 as your target framework, your tests are run in the .NET 1.1 framework. The project's target framework can be set by selecting Project Options from the Project menu, then opening the Compiling tab.

Only .NET 1.1 and .NET 2.0 are supported, so if you choose another framework, such as one of the Compact Frameworks or Mono SharpDevelop will run your unit tests under .NET 2.0.

There's currently no support for Mono because our modified nunit-console has a threading problem which happens very frequently under Mono, but never seems to occur under Microsoft's .NET Framework.

Running under another .NET Framework

Since SharpDevelop recently moved to using nunit-console to run unit tests it was a fairly simple task to make it possible to test against .NET 1.1 or .NET 2.0. It is straight forward because nunit-console can be compiled against .NET 1.1. Since SharpDevelop is launching nunit-console as a separate process we could have used one of the following to target one particular framework.

app.config
COMPLUS_Version environment variable

App.Config

Using an app.config file is the most obvious and well documented way to target a particular framework and is actually how SharpDevelop gets nunit-console to target the different frameworks.

To run unit tests with .NET 1.1 we have nunit-console.exe built against .NET 1.1 and an app.config file, called nunit-console.exe.config which, contains the following:

<configuration>
    <!--  
        The startup section may be used to specify the runtime versions supported
        in the order that they will be used if more than one is present.
    --> 
    <startup> 
        <supportedRuntime version="v1.1.4322" /> 
    </startup> 
</configuration>

Note that the actual nunit-console's actual app.config has some extra things which I have removed in the above example so it just shows what is needed to target a particular framework. The <supportedRuntime> element is used to determine which framework the application is run against.

To run against .NET 2.0 we use the same copy of nunit-console, built against .NET 1.1, but with an app.config which has .NET 2.0 as the supported runtime. When you run the unit tests SharpDevelop looks at the project's target framework and runs the corresponding nunit-console.

COMPlus_Version

With Microsoft's .NET framework you can set the COMPlus_Version environment variable before running your .NET application to run it under a particular framework. So at the command line you could execute

SET COMPLUS_Version=v1.1.4322

Then your application would run against .NET 1.1. Specifying a framework in your app.config will override the COMPLUS_Version setting however.

SharpDevelop does not use this method since using an app.config makes it easy to support running unit tests with NCover and the debugger. Using COMPLUS_Version we could not run NCover since it is compiled against .NET 2.0. The debugger would also need to be modified so it could set environment variables before debugging an application.

Mono

How do we target another framework with Mono? You can use one of the following:

app.config
mono.exe --runtime command line parameter

Again we can use the app.config file as discussed previously. We can also use the new --runtime command line parameter that was added in Mono 1.2.2. This works in a similar way to the COMPLUS_Version environment variable allowing you to set the framework version globally. Using the command line

mono --runtime=v1.1.4322 nunit-console.exe

would run nunit-console under Mono's .NET 1.1 framework.

There is one difference though, specifying the target framework in the app.config does not override this command line setting.

Code Coverage with .NET 1.1

If you want to look at code coverage when running your unit tests under .NET 1.1 you will need to use NCover version 1.5.4 since the latest release 1.5.5 does not work produce any coverage results when profiling a .NET 1.1 assembly.

Targeting Different Frameworks with VB.NET

MattWard — Sat, 18 Feb 2006 17:09:00 GMT

SharpDevelop 2.1, revision 1157, allows VB.NET projects to target the older Microsoft Frameworks and Mono. This extends Daniel's previous work to target different frameworks with C#. SharpDevelop 2.1 is only available from the repository.

To target a different framework, open the project's "Compiling" options (Project | Project Options | Compiling) and select the desired framework from the "Target Framework" drop down list.

MonoBASIC

When Mono is targeted, the MonoBASIC compiler (mbas) will be used. This compiler is still under going a lot development, so there are a few things that are missing or have incomplete support. One omission, for example, is that it will not embed resources into an assembly.

SharpDevelop now contains Gtk# project and file templates for VB.NET. There is no Glade# project template for VB.NET since MonoBASIC does not currently support embedded resources.

Issues

There are a few things to be aware of when using SharpDevelop to target the older frameworks.

Code completion for certain core assemblies will only show .NET 2.0 information. These core assemblies are:

mscorlib
System
System.Data
System.Design
System.DirectoryServices
System.Drawing
System.Web.Services
System.Windows.Forms
System.Xml
Microsoft.Build.Engine
Microsoft.Build.Framework

The Forms Designer will generate .NET 2.0 code only.

The Forms Designer will generate .NET 2.0 specific resources.

Alternative Solutions

Robert McLaws produced an MSBuild toolkit for Visual Studio 2005 RC, but this does not look like it supports the latest version of Visual Studio.

Jomo Fisher produced a targets file, for C# projects, that can be used to target the older Microsoft frameworks. This targets file is a sample that supports Visual Studio beta 2.

Microsoft recently released an MSBuild toolkit for .NET 1.1 called MSBee. This adds support for targeting .NET 1.1 with VB.NET as well as C# projects. It will also generate .NET 1.x resources from .NET 2.0 resx files.

[Update 30 August 2006]

From version 1.1.17 Mono no longer ships with the MonoBASIC compiler. When the new VB compiler for Mono is released SharpDevelop 2.1 will be updated to support it.

MSBuild and Mono's GAC

MattWard — Wed, 11 Jan 2006 21:13:00 GMT

SharpDevelop2 now supports Mono's GAC, so this post takes a low level look into how it uses MSBuild to do this.

Our starting point is a previous Custom MSBuild Targets for Mono post, which introduced an MSBuild task (Mcs), which was used to compile the code using Mono's Mcs compiler, and an MSBuild targets file (Mono.Mcs.targets). We will be using the ICSharpCode.Build.Tasks assembly that ships with SharpDevelop2 which contains the custom MSBuild tasks. We will not be using the SharpDevelop2's target files since these target more than just the Mono framework.

Mono GAC References

The original custom MSBuild task and targets file did not support Mono GAC references. In fact they were the bare minimum required to compile code using Mcs. The only MSBuild target that was overridden was the CoreCompile target, which was changed to use the Mcs task instead of Microsoft's Csc task. Without support for Mono's GAC any assembly references needed to have a HintPath

<Reference Include="gtk-sharp">
<HintPath>..\..\Program Files\Mono\lib\mono\gtk-sharp\gtk-sharp.dll</HintPath>
</Reference>

In order to add support for Mono's GAC we will need to look at the following Microsoft targets and properties:

AssemblySearchPaths
GetFrameworkPaths
ResolveAssemblyReferences

First let us see if we can get a simple GAC reference to System.Xml to work. With the old tasks and targets a reference of the form

<Reference Include="System.Xml"/>

is resolved to "C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.Xml.dll".

To fix this we need to override the GetFrameworkPaths target and set the TargetFrameworkDirectory property correctly. This can be done by adding the following to the Mono.Mcs.targets file

<Target Name="GetFrameworkPaths">
    
    <GetMonoFrameworkPath TargetFrameworkVersion="Mono v1.1">
        <Output TaskParameter="Path" PropertyName="TargetFrameworkDirectory"/>
        <Output TaskParameter="Path" ItemName="_TargetFrameworkDirectoryItem"/>
    </GetMonoFrameworkPath>

    
    <GetMonoFrameworkSDKPath>
        <Output TaskParameter="Path" PropertyName="TargetFrameworkSDKDirectory"/>
        <Output TaskParameter="Path" ItemName="_TargetFrameworkSDKDirectoryItem"/>
    </GetMonoFrameworkSDKPath>
</Target>

This override must come after the

<Import Project="$(MSBuildBinPath)\Microsoft.Common.targets" />

statement, so this should be moved to the beginning of the Mono.Mcs.targets file. It also uses two custom tasks that need to be made known to MSBuild

<UsingTask TaskName="ICSharpCode.Build.Tasks.GetMonoFrameworkPath"
           AssemblyFile="ICSharpCode.Build.Tasks.dll"/>
<UsingTask TaskName="ICSharpCode.Build.Tasks.GetMonoFrameworkSdkPath"
           AssemblyFile="ICSharpCode.Build.Tasks.dll"/>

The GetFrameworkPaths target sets a few more things than just the TargetFrameworkDirectory, this is done for completeness based on what the Microsoft.Common.targets file does, but only the TargetFrameworkDirectory property needs to be set. The TargetFrameworkDirectory is set by calling the GetMonoFrameworkPath task and passing in the target framework version, which in this case is "Mono v1.1". This task uses the registry to locate the Mono framework directory (e.g. "C:\Program Files\Mono\lib\mono\1.0").

AssemblySearchPaths and ResolveAssemblyReference

Now what about an assembly that only exists in Mono's GAC and cannot be found in Mono framework's directory? A reference to glib-sharp is a good place to start.

<Reference Include="glib-sharp, Version=1.0.0.0, Culture=neutral, PublicKeyToken=35e10195dab3c99f"/>

We need to modify the AssemblySearchPaths which is being passed to the ResolveAssemblyReference task. In the Microsoft's target files this is defined as:

<PropertyGroup>
    
    <AssemblySearchPaths Condition=" '$(AssemblySearchPaths)' == '' ">
        {CandidateAssemblyFiles};
        $(ReferencePath);
        {HintPathFromItem};
        {TargetFrameworkDirectory};
        {Registry:$(FrameworkRegistryBase),$(TargetFrameworkVersion),$(AssemblyFoldersSuffix)$(AssemblyFoldersExConditions)};
        {AssemblyFolders};
        {GAC};
        {RawFileName};
        $(OutputPath)
    </AssemblySearchPaths>
</PropertyGroup>

The {Registry} part is Microsoft specific and can be removed for Mono. The {GAC} part is also Microsoft specific. When the ResolveAssemblyReference task encounters this string it knows to look in Microsoft's GAC. We will replace this with {MonoGAC} which Microsoft's ResolveAssemblyReference task knows nothing about.

<PropertyGroup>
    <AssemblySearchPaths>
        {CandidateAssemblyFiles};
        $(ReferencePath);
        {HintPathFromItem};
        {TargetFrameworkDirectory};
        {AssemblyFolders};
        {MonoGAC};
        {RawFileName};
        $(OutputPath)
    </AssemblySearchPaths>
</PropertyGroup>

Now we need to somehow replace the {MonoGAC} with a set of directories. We could write our own ResolveAssemblyReference task, but this seems like a lot of work. Instead let us update the AssemblySearchPaths just before the ResolveAssemblyReference task is called. We do this by overriding the ResolveAssemblyReferenceDependsOn target and making it call our custom AddMonoAssemblySearchPaths target.

<PropertyGroup>
    <ResolveAssemblyReferencesDependsOn>
        GetFrameworkPaths;
        GetRedistLists;
        PrepareForBuild;
        AddMonoAssemblySearchPaths
    </ResolveAssemblyReferencesDependsOn>
</PropertyGroup>
<Target Name="AddMonoAssemblySearchPaths">
    <AddMonoAssemblySearchPaths
        Assemblies="@(Reference)"
        Paths="$(AssemblySearchPaths)">
        <Output TaskParameter="Paths" PropertyName="AssemblySearchPaths"/>
    </AddMonoAssemblySearchPaths>
</Target>

Again this custom task needs to be included via

<UsingTask TaskName="ICSharpCode.Build.Tasks.AddMonoAssemblySearchPaths"
           AssemblyFile="ICSharpCode.Build.Tasks.dll"/>

The AddMonoAssemblySearchPath task looks for the {MonoGAC} item in the AssemblySearchPaths property and replaces it with any Mono GAC directories that need to be searched. The GAC directories are determined by looking at the assembly references passed in via the Assemblies property. If multiple GAC references are located then multiple directories are inserted into the AssemblySearchPaths property.

Now we can use MSBuild to build a project with references to assemblies in Mono's GAC using SharpDevelop2's ICSharpCode.Build.Tasks assembly and the Mono.Mcs.targets file.

Mono.Mcs.targets

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" DefaultTargets="Build">

    <Import Project="$(MSBuildBinPath)\Microsoft.Common.targets" />

    <UsingTask TaskName="ICSharpCode.Build.Tasks.Mcs"
               AssemblyFile="ICSharpCode.Build.Tasks.dll"/>
     <UsingTask TaskName="ICSharpCode.Build.Tasks.GetMonoFrameworkPath"
               AssemblyFile="ICSharpCode.Build.Tasks.dll"/>
     <UsingTask TaskName="ICSharpCode.Build.Tasks.GetMonoFrameworkSdkPath"
               AssemblyFile="ICSharpCode.Build.Tasks.dll"/>
     <UsingTask TaskName="ICSharpCode.Build.Tasks.AddMonoAssemblySearchPaths"
               AssemblyFile="ICSharpCode.Build.Tasks.dll"/>

   <PropertyGroup>
        <MSBuildAllProjects>$(MSBuildAllProjects);Mono.Mcs.targets</MSBuildAllProjects>
        <DefaultLanguageSourceExtension>.cs</DefaultLanguageSourceExtension>
        <Language>C#</Language>
    </PropertyGroup>

    <Target Name="CreateManifestResourceNames"/>

    <PropertyGroup>
        <DebugSymbols Condition=" '$(DebugType)' == 'none' ">false</DebugSymbols>
        <DebugType    Condition=" '$(DebugType)' == 'none' "></DebugType>
    </PropertyGroup>

    <ItemGroup>
        <DocFileItem Include="$(DocumentationFile)" Condition="'$(DocumentationFile)'!=''">
            <InProject>false</InProject>
        </DocFileItem>
    </ItemGroup>

    <PropertyGroup>
        <CoreCompileDependsOn>_ComputeNonExistentFileProperty</CoreCompileDependsOn>
    </PropertyGroup>

   
   <PropertyGroup>
        <AssemblySearchPaths>
            {CandidateAssemblyFiles};
            $(ReferencePath);
            {HintPathFromItem};
            {TargetFrameworkDirectory};
            {AssemblyFolders};
            {MonoGAC};
            {RawFileName};
            $(OutputPath)
        </AssemblySearchPaths>
    </PropertyGroup>

    
    <PropertyGroup>
        <ResolveAssemblyReferencesDependsOn>
            GetFrameworkPaths;
            GetRedistLists;
            PrepareForBuild;
            AddMonoAssemblySearchPaths
        </ResolveAssemblyReferencesDependsOn>
    </PropertyGroup>
    <Target Name="AddMonoAssemblySearchPaths">
        <AddMonoAssemblySearchPaths
            Assemblies="@(Reference)"
            Paths="$(AssemblySearchPaths)">

            <Output TaskParameter="Paths" PropertyName="AssemblySearchPaths"/>
        </AddMonoAssemblySearchPaths>
    </Target>

    <Target    Name="GetFrameworkPaths">
        
        <GetMonoFrameworkPath TargetFrameworkVersion="Mono v1.1">
            <Output TaskParameter="Path" PropertyName="TargetFrameworkDirectory"/>
            <Output TaskParameter="Path" ItemName="_TargetFrameworkDirectoryItem"/>
        </GetMonoFrameworkPath>

        
        <GetMonoFrameworkSDKPath>
            <Output TaskParameter="Path" PropertyName="TargetFrameworkSDKDirectory"/>
            <Output TaskParameter="Path" ItemName="_TargetFrameworkSDKDirectoryItem"/>
        </GetMonoFrameworkSDKPath>
    </Target>

    <Target
        Name="CoreCompile"
        Inputs="$(MSBuildAllProjects);
                @(Compile);
                @(ManifestResourceWithNoCulture);
                $(ApplicationIcon);
                $(AssemblyOriginatorKeyFile);
                @(ManifestNonResxWithNoCultureOnDisk);
                @(ReferencePath);
                @(CompiledLicenseFile)"
        Outputs="@(DocFileItem);
                 @(IntermediateAssembly);
                 $(NonExistentFile)"
        DependsOnTargets="$(CoreCompileDependsOn)"
    >

        <Mcs
              AdditionalLibPaths="$(AdditionalLibPaths)"
              AddModules="@(AddModules)"
              AllowUnsafeBlocks="$(AllowUnsafeBlocks)"
              CheckForOverflowUnderflow="$(CheckForOverflowUnderflow)"
              CodePage="$(CodePage)"
              DebugType="$(DebugType)"
              DefineConstants="$(DefineConstants)"
              DelaySign="$(DelaySign)"
              DisabledWarnings="$(NoWarn)"
              DocumentationFile="@(DocFileItem)"
              EmitDebugInformation="$(DebugSymbols)"
              KeyContainer="$(KeyContainerName)"
              KeyFile="$(KeyOriginatorFile)"
              LangVersion="$(LangVersion)"
              MainEntryPoint="$(StartupObject)"
              NoConfig="true"
              NoLogo="$(NoLogo)"
              NoStandardLib="$(NoStdLib)"
              Optimize="$(Optimize)"
              OutputAssembly="@(IntermediateAssembly)"
              References="@(ReferencePath)"
              Resources="@(ManifestResourceWithNoCulture);@(ManifestNonResxWithNoCultureOnDisk);@(CompiledLicenseFile)"
              ResponseFiles="$(CompilerResponseFile)"
              Sources="@(Compile)"
              TargetType="$(OutputType)"
              ToolPath="$(McsToolPath)"
              TreatWarningsAsErrors="$(TreatWarningsAsErrors)"
              WarningLevel="$(WarningLevel)"
              Win32Icon="$(ApplicationIcon)"
              Win32Resource="$(Win32Resource)" />
    </Target>
</Project>

SharpDevelop2 and Mono's GAC

MattWard — Tue, 10 Jan 2006 13:43:00 GMT

In revision 983 SharpDevelop2 has support for Mono's GAC. It also includes new Gtk# and Glade# project templates, and a Gtk# Window file template. Mono can be downloaded from here

Creating a new Glade# Project

Select the menu option File | New | Solution to open the "New Project" dialog.
Select the C# category.
There are two new projects here, a Gtk# project and a Glade# project. Select the Glade# project.
Enter a name for the project and select the "Create" button to generate the project.

The generated project will target Mono 1.1 by default, and will use Mono's Mcs compiler.

Running the Glade# Application

If you have the Mono bin directory (e.g. C:\Program Files\Mono\bin) added to your Path environment variable, the project can be started by selecting the menu option Debug | Run or Debug | Run without debugger. This will run the application under the Microsoft .NET framework and not Mono itself, to run under Mono see this post.

Note that you cannot debug the application when it is built with either of the Mono compilers.

Adding a Mono GAC Reference

Open the Project Browser via View | Project.
Select the "References" node, right click and select "Add Mono Reference".
Select the GAC entry that will be added to the project, click the Select button and then click the OK button to add the reference to the project.

Code Completion

There is a small problem with code auto-completion. In order for auto-completion to work the reference must be added via the "Add Mono Reference" dialog. So the first time a Glade# or Gtk# project has been created you will have to remove the GAC references and then re-add them to get code auto-completion working. This only needs to be done once, not every time a Gtk# or Glade# project is created.

Debugging a Mono Application

You cannot debug a Mono app built using Mcs or Gmcs. The Mono compilers create their own open source debugging symbols binary (.mdb) which SharpDevelop and Microsoft's DbgCLR do not support. There is also no Mono debugger available for Windows. In order to debug a Mono app it needs to be built using the Microsoft Csc compiler. The general guidelines to be able to debug your Mono app using the SharpDevelop debugger are:

Make sure all Mono specific GAC references have "Local Copy" set to true. Select the reference in the Project Browser and select Properties to set this.
The Mono bin directory (e.g. C:\Program Files\Mono\bin) must be added to the Path environment variable.
Change the "Target Framework" (Project | Project Options | Compiling) to one of the Microsoft .NET frameworks.
Remove and re-add your Mono GAC references using the "Add Mono Reference" dialog. You should only need to do this once and only if you are using a project created from the Glade# or Gtk# templates. Doing this will add a HintPath to the references in your MSBuild project so the Microsoft compilers can locate the assemblies in the Mono GAC. These HintPaths are not currently added to a newly created Glade/Gtk# project.
Rebuild your application.

Once the HintPaths have been added to your MSBuild project you should be able to switch between the Microsoft and Mono frameworks as required, and build your code using the Microsoft or Mono compilers.

If you are going to debug a Gtk# or Glade# application you will need to add extra GAC references. Mcs and Gmcs do not need all Gtk# references to be added, but Microsoft's Csc compiler does. For a Gtk# app you will need at least:

atk-sharp
gdk-sharp
glib-sharp
gtk-sharp
pango-sharp

Also add glade-sharp if you are developing a Glade# app.

Links

Mono Downloads
Targeting Mono with SharpDevelop2
SharpDevelop Daily Builds

Creating a Gtk# App with SharpDevelop 2.0 Using Glade

MattWard — Thu, 20 Oct 2005 15:40:00 GMT

The starting point is the Glade xml file.

Glade xml file

This was created using the Glade UI Builder that ships with the Mono installer. The xml file specifies the UI components and signals (events) for these components. In our case the main components we have are a mainWindow and a messageLabel. There is also a delete_event signal defined for the main window named MainWindowDeleteEvent.

<?xml version="1.0" standalone="no"?> 
<!DOCTYPE glade-interface SYSTEM "http://glade.gnome.org/glade-2.0.dtd">

<glade-interface>

<widget class="GtkWindow" id="mainWindow">
  <property name="visible">True</property>
  <property name="title" translatable="yes">Hello, Gtk# World</property>
  <property name="type">GTK_WINDOW_TOPLEVEL</property>
  <property name="window_position">GTK_WIN_POS_NONE</property>
  <property name="modal">False</property>
  <property name="default_width">300</property>
  <property name="default_height">300</property>
  <property name="resizable">True</property>
  <property name="destroy_with_parent">False</property>
  <property name="decorated">True</property>
  <property name="skip_taskbar_hint">False</property>
  <property name="skip_pager_hint">False</property>
  <property name="type_hint">GDK_WINDOW_TYPE_HINT_NORMAL</property>
  <property name="gravity">GDK_GRAVITY_NORTH_WEST</property>
  <signal name="delete_event" handler="MainWindowDeleteEvent" last_modification_time="Thu, 20 Oct 2005 13:24:07 GMT"/>

  <child>
    <widget class="GtkLabel" id="messageLabel">
      <property name="visible">True</property>
      <property name="label" translatable="yes">Message here...</property>
      <property name="use_underline">False</property>
      <property name="use_markup">False</property>
      <property name="justify">GTK_JUSTIFY_LEFT</property>
      <property name="wrap">False</property>
      <property name="selectable">False</property>
      <property name="xalign">0.5</property>
      <property name="yalign">0.5</property>
      <property name="xpad">0</property>
      <property name="ypad">0</property>
    </widget>
  </child>
</widget>

</glade-interface>

Now we need to create a SharpDevelop project to add this Glade xml file to.

Create a new empty project

Select File | New | Solution to open the "New Project" dialog.
Select the C# category and the "Empty Project" template. Enter in project name "HelloGtkWorld" and choose a location. Click the "Create" button to create your empty project.

Remove all unwanted assembly references

Select View | Projects to open up the project browser.
Expand the tree so the assembly references are displayed. There should be two, System and System.Xml. Select one at a time, right click and select "Remove". Repeat until all references have been removed.

Add a Glade xml file to the project

Select the project tree node, right click and select Add | New Item... to open the "New File" dialog.
Select the Misc category and the "Empty XML file" template. Type in the name "glade.xml" and click the "Create" button.
Modify the glade.xml file so it contains the xml shown above.
Embed this xml file as a resource. Select the file in the Project Browser. Select the menu View | Properties. Change the "Build action" to "EmbeddedResource".

Create a new C# class that will be the main entry point for the application

Open the project browser again. Select the project tree node, right click and select Add | New Item... to open the "New File" dialog.
Select the C# category and the Class template. Type in the filename GladeApp.cs and click the "Create" button to add the new C# class file to the project.
This file should be opened when created. Modify the code so the file contains:

using Glade;
using Gtk;
using System;

public class GladeApp
{
    [Widget]
    Label messageLabel;

    public static void Main (string[] args)
    {
        new GladeApp (args);
    }

    public GladeApp (string[] args)
    {
        Application.Init();
        Glade.XML gxml = new Glade.XML(null, "HelloGtkWorld.glade.xml", "mainWindow", null);
        gxml.Autoconnect(this);
        messageLabel.Text = "Hello, Gtk# World.";
        Application.Run();
    }

    void MainWindowDeleteEvent(object o, DeleteEventArgs args)
    {
        Application.Quit();
        args.RetVal = true;
    }
}

Let us have a look at this code before we attempt to make sure it compiles. The main part of interest is in the GladeApp class's constructor. First Gtk is initialised:

Application.Init();

This must be called before any Gtk libraries are used.

Then a Glade.XML object is created that will use our "glade.xml" file which has been embedded as a resource. Note that the resource name is the name of the file with the project's namespace prefixed "HelloGtkWorld.gui.xml".

Glade.XML gxml = new Glade.XML(null, "HelloGtkWorld.glade.xml", "mainWindow", null);

The Autoconnect call connects the signals defined in the Glade xml file to matching handlers in the GladeApp class. It will also initialise any fields that correspond to UI components defined in the Glade xml file.

gxml.Autoconnect(this);

The next line sets the text of the label that will be displayed in the main window.

messageLabel.Text = "Hello, Gtk# World.";

The messageLabel object

[Widget]
Label messageLabel;

will auto-magically be initialised for us by the Glade.Xml object.

Finally the application is run via:

Application.Run();

When the user closes the main window the MainWindowDeleteEvent method is called.

    void MainWindowDeleteEvent(object o, DeleteEventArgs args)
    {
        Application.Quit();
        args.RetVal = true;
    }

This method makes sure the application quits. If the Application.Quit method is not called then even though the main window has been closed the app will still be running in the background.

Add references to the Glade and Gtk assemblies.

Open the Project Browser. Select the "References" node, right click and select "Add References".
In the "Add Reference" dialog select the ".NET Assembly Browser" tab and click the "Browse..." button.
Browse to the Mono folder containing the assemblies for Glade and Gtk#. The folder should be something like "C:\Program Files\Mono\lib\mono\gtk-sharp". Select the glade-sharp and gtk-sharp dlls and click the "Open" button. In the "Add Reference" dialog click the "OK" button.

Compiling the code

Select the menu item Project | Project Options. In the "Application" tab, change the "Output type" to be "Windows Application".
In the "Compiling" tab, change the "Target framework" to "Mono 1.1".
In the "Debug" tab, change the "Start Action" to "Start external program". Set the external program field by browsing and selecting Mono.exe, which lives in "C:\Program Files\Mono\bin". In the "Start Options" group set the "Command line arguments to be "${TargetPath}" and the "Working directory" to "${TargetDir}".
Select the menu Build | Rebuild Solution. The code should build successfully. There will be two warnings, one about MainWindowDeleteEvent method never being called and another about the messageLabel variable never being assigned to, both of which can be safely ignored.

It is optional whether you use the Mono as the Target framework, the Gtk# and Glade libraries should work under the .NET framework. You will have to add references to the Glib and Atk libraries to be able to compile using Csc.

Running the app

Select the menu Debug | Run without debugger.

As with the target framework, it is optional whether you run the application under Mono since the Gtk# and Glade libraries should work under the .NET framework.

Other Useful Resources

Introduction to Mono - Your first Mono app - Covers creating a Mono console app.

A google search application using Gtk# - Uses Visual Studio to create a Gtk# Mono app that uses Google's web service.

A Gtk# beginners guide. - Covers Gtk# and Glade.

GUI development with Glade - A tutorial covering the Glade User Interface Builder.

Mono Documentation - Covers all the Mono libraries including Gtk# and Glade.

[Update: 10 Jan, 2006]

SharpDevelop2 now ships with Gtk# and Glade# templates. Support for Mono's GAC has also been added. Read more here.

Detecting Where Mono is Installed

MattWard — Mon, 17 Oct 2005 21:19:00 GMT

Whilst looking at the NAnt config file (Nant.exe.config), I noticed that NAnt does a much better job at detecting where the Mono compilers, Mcs and Gmcs, are located. NAnt reads the registry, whilst SharpDevelop assumes that they exist somewhere in a folder, typically "C:\Program Files\Mono\bin", that has been added to the Path environment variable. If you add the "C:\Program Files\Mono\bin" folder to the Path then everything should work. In this bin folder there are several .bat files that can be used to run the various Mono compilers, and these are what SharpDevelop uses. The Mono executables live in "C:\Program Files\Mono\lib\mono\1.0" and "C:\Program Files\Mono\lib\mono\2.0", depending on the framework being targeted, and the .bat files run these executables under Mono.

Mono's Registry Settings

When you install Mono under Windows the installer adds a registry key under HKEY_LOCAL_MACHINE\SOFTWARE\Novell\Mono, and the values entered here can be used to detect where Mono is.

[HKEY_LOCAL_MACHINE\SOFTWARE\Novell\Mono]
DefaultCLR=1.1.9.2

[HKEY_LOCAL_MACHINE\SOFTWARE\Novell\Mono\1.1.9.2]
FrameworkAssemblyDirectory=C:\Program Files\Mono\lib
MonoConfigDir=C:\Program Files\Mono\etc
SdkInstallRoot=C:\Program Files\Mono

SharpDevelop will now use the registry to locate the Mono bin folder, and if this fails then it falls back on its original method of assuming that the compiler lives in a folder added to the Path.

This small improvement has been added to SharpDevelop 2.0 in revision 593.

Custom MSBuild Tasks for Mono

MattWard — Sat, 15 Oct 2005 14:15:00 GMT

SharpDevelop ships with two custom MSBuild tasks for Mono, one for Mcs and the other for Gmcs, both of which live in the ICSharpCode.Build.Tasks assembly. With the recent Mono release, 1.1.9, the command line options and compiler error message formats are the same for Mcs and Gmcs, earlier versions differed. This means that the Mcs and Gmcs classes do not do much apart from determine the name of the compiler to use. The MonoCompilerTask class does the hard work of compiling the code and reporting error messages back.

Simple C# Console Project

HelloMonoWorld.csproj:

<Project DefaultTargets="Build"
         xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <AssemblyName>HelloMonoWorld</AssemblyName>
    <WarningLevel>4</WarningLevel>
  </PropertyGroup>
  <PropertyGroup>
    <OutputPath>bin</OutputPath>
  </PropertyGroup>
  <ItemGroup>
    <Compile Include="Main.cs" />
    <Compile Include="AssemblyInfo.cs" />
  </ItemGroup>
  <Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />
</Project>

Main.cs:

using System;

namespace HelloMonoWorld
{
    class MainClass
    {
        public static void Main(string[] args)
        {
            Console.WriteLine("Hello World!");
        }
    }
}

Running MSBuild, passing the .csproj as a command line argument, will build the console app using Microsoft's Csc and targets the .NET Framework 2.0.

Using the Mcs Task Directly

Let us modify the project file so it calls the Mcs task directly. I am assuming that the ICSharpCode.Build.Tasks.dll exists in the same folder as the project file.

<Project DefaultTargets="Build"
         xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <AssemblyName>HelloMonoWorld</AssemblyName>
    <WarningLevel>4</WarningLevel>
  </PropertyGroup>
  <PropertyGroup>
    <OutputPath>bin</OutputPath>
  </PropertyGroup>
  <ItemGroup>
    <Compile Include="Main.cs" />
    <Compile Include="AssemblyInfo.cs" />
  </ItemGroup>

  <UsingTask TaskName="ICSharpCode.Build.Tasks.Mcs"
             AssemblyFile="ICSharpCode.Build.Tasks.dll"/>

  <Target Name="Build">
    <Mcs
      OutputAssembly="$(OutputPath)\$(AssemblyName).exe"
      References="@(ReferencePath)"
      Sources="@(Compile)"
      TargetType="$(OutputType)"/>
  </Target>
</Project>

The project file above is a bit limited, it does not have standard targets such as "Rebuild" and "Clean". We could write everything ourselves, but instead why not use the standard .targets that Microsoft provides and just override the bare minimum?

Mono.Mcs.targets

So what is the bare minimum .targets file we need in order to get MSBuild to use our custom Mono tasks?

First let us look at the modified project file:

<Project DefaultTargets="Build"
         xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <AssemblyName>HelloMonoWorld</AssemblyName>
    <WarningLevel>4</WarningLevel>
  </PropertyGroup>
  <PropertyGroup>
    <OutputPath>bin</OutputPath>
  </PropertyGroup>
  <ItemGroup>
    <Compile Include="Main.cs" />
    <Compile Include="AssemblyInfo.cs" />
  </ItemGroup>
  <Import Project="Mono.Mcs.targets" />
</Project>

The Mono.Mcs.targets file, which is based on the Microsoft.CSharp.targets file, overrides the CoreCompile target:

<Project DefaultTargets="Build"
         xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

    <UsingTask TaskName="ICSharpCode.Build.Tasks.Mcs"
               AssemblyFile="ICSharpCode.Build.Tasks.dll"/>

   <PropertyGroup>
        <MSBuildAllProjects>$(MSBuildAllProjects);Mono.Mcs.targets</MSBuildAllProjects>
        <DefaultLanguageSourceExtension>.cs</DefaultLanguageSourceExtension>
        <Language>C#</Language>
    </PropertyGroup>

    <Target Name="CreateManifestResourceNames"/>

    <PropertyGroup>
        <DebugSymbols Condition=" '$(DebugType)' == 'none' ">false</DebugSymbols>
        <DebugType    Condition=" '$(DebugType)' == 'none' "></DebugType>
    </PropertyGroup>

    <ItemGroup>
        <DocFileItem Include="$(DocumentationFile)" Condition="'$(DocumentationFile)'!=''">
            <InProject>false</InProject>
        </DocFileItem>
    </ItemGroup>

    <PropertyGroup>
        <CoreCompileDependsOn>_ComputeNonExistentFileProperty</CoreCompileDependsOn>
    </PropertyGroup>

    <Target
        Name="CoreCompile"
        Inputs="$(MSBuildAllProjects);
                @(Compile);
                @(ManifestResourceWithNoCulture);
                $(ApplicationIcon);
                $(AssemblyOriginatorKeyFile);
                @(ManifestNonResxWithNoCultureOnDisk);
                @(ReferencePath);
                @(CompiledLicenseFile)"
        Outputs="@(DocFileItem);
                 @(IntermediateAssembly);
                 $(NonExistentFile)"
        DependsOnTargets="$(CoreCompileDependsOn)"
    >

        <Mcs
              AdditionalLibPaths="$(AdditionalLibPaths)"
              AddModules="@(AddModules)"
              AllowUnsafeBlocks="$(AllowUnsafeBlocks)"
              CheckForOverflowUnderflow="$(CheckForOverflowUnderflow)"
              CodePage="$(CodePage)"
              DebugType="$(DebugType)"
              DefineConstants="$(DefineConstants)"
              DelaySign="$(DelaySign)"
              DisabledWarnings="$(NoWarn)"
              DocumentationFile="@(DocFileItem)"
              EmitDebugInformation="$(DebugSymbols)"
              KeyContainer="$(KeyContainerName)"
              KeyFile="$(KeyOriginatorFile)"
              LangVersion="$(LangVersion)"
              MainEntryPoint="$(StartupObject)"
              NoConfig="true"
              NoLogo="$(NoLogo)"
              NoStandardLib="$(NoStdLib)"
              Optimize="$(Optimize)"
              OutputAssembly="@(IntermediateAssembly)"
              References="@(ReferencePath)"
              Resources="@(ManifestResourceWithNoCulture);@(ManifestNonResxWithNoCultureOnDisk);@(CompiledLicenseFile)"
              ResponseFiles="$(CompilerResponseFile)"
              Sources="@(Compile)"
              TargetType="$(OutputType)"
              ToolPath="$(McsToolPath)"
              TreatWarningsAsErrors="$(TreatWarningsAsErrors)"
              WarningLevel="$(WarningLevel)"
              Win32Icon="$(ApplicationIcon)"
              Win32Resource="$(Win32Resource)" />
    </Target>

    <Import Project="$(MSBuildBinPath)\Microsoft.Common.targets" />
</Project>

The differences between this is and the standard Microsoft.CSharp.targets file is that a few properties have been removed (NoWarn and UseHostCompilerIfAvailable) and the CreateManifestResourceNames target has essentially been removed, the target is defined, but it does nothing. This targets file is good enough to compile our console application, as long as we do not add any embedded resources to it.

SharpDevelop

How does this compare with the .targets files that ship with SharpDevelop? Since SharpDevelop can target more than just Mono, it supports the older .NET frameworks too, things are a little more complicated. This will be covered in another post.

SharpDevelop 2.0 and Mono

MattWard — Wed, 12 Oct 2005 22:16:00 GMT

As of revision 568, available from the repository, SharpDevelop 2.0 supports C# projects targeting Mono 1.1.9.2.

Prerequisites

Mono 1.1.9.2 is installed.
The Mono bin folder has been added to the "Path" environment variable (Control Panel | System | Advanced | Environment Variables).

Targeting Mono

To target Mono, open the project's "Compiling" options (Project | Project Options | Compiling) and select either "Mono 1.1" or "Mono 2.0" from the "Target Framework" drop down list.

With "Mono 1.1" selected the Mcs compiler will be used. With "Mono 2.0" selected the Gmcs compiler will be used.

Running your Application

After you have compiled your code using Mcs or Gmcs you can then run your application under Microsoft's .NET Framework or under Mono's Framework. If you want to run it under Microsoft's .NET Framework then you can use either of the menu options "Debug | Run" or "Debug | Run without debugger" as you would with a normal application created using SharpDevelop. You will need to make sure all the Mono specific assembly references (e.g. glib-sharp) have "Local Copy" set to "true", otherwise the Microsoft .NET Framework will be unable to find them. If you want to run your application under Mono's Framework instead follow the instructions in the next section.

Running under Mono

To configure your application to run under Mono's Framework, open the project's "Debug" options (Project | Project Options | Debug), switch the "Start Action" to "Start external program" and enter the path to the Mono executable, and finally set the "Command line arguments" to "${TargetPath}". If the path to your application's executable contains spaces put double quotes around the ${TargetPath} string.

To run your application under Mono, select the menu option Debug | Run without debugger. You cannot use the SharpDevelop debugger to debug or run your Mono application.

Common Problems

Mcs/Gmcs exiting with code -1

If you are seeing errors such as:

"Mcs.exe" exited with code -1
Failed to execute compiler: -1: "C:\Program Files\Mono\bin\Mcs.bat"

This is usually because Mono cannot convert the command line into Unicode. To fix this create a environment variable called MONO_EXTERNAL_ENCODINGS and set it to be "default_locale" without the quotes.

From the Mono man page:

MONO_EXTERNAL_ENCODINGS

If set, contains a colon-separated list of text encodings to try when turning externally-generated text (e.g. command-line arguments or filenames) into Unicode. The encoding names come from the list provided by iconv, and the special case "default_locale" which refers to the current locale's default encoding.

When reading externally-generated text strings UTF-8 is tried first, and then this list is tried in order with the first successful conversion ending the search. When writing external text (e.g. new filenames or arguments to new processes) the first item in this list is used, or UTF-8 if the environment variable is not set.

[UPDATE 6th March, 2006]

Added MONO_EXTERNAL_ENCODINGS fix for the Mcs/Gmcs compiler failing with error code -1. Thanks to Luis Segura for finding this solution.

[UPDATE 10th April, 2006]

Added some information about running under Microsoft's .NET Framework versus running under Mono. Added a note about putting double quotes around ${TargetPath} if the path to the executable being run under Mono contains spaces.