Suggestions for a Windows D-Bus client development environment

Alp Toker alp at
Thu Apr 16 04:34:39 PDT 2009

Hi Glenn,

I'm going to paraphrase our conversation from the NDesk D-Bus bug
tracker for the benefit of the list along with some new comments.

2009/4/15 Schmottlach, Glenn <glenn.schmottlach at>:
> I next tried building the NDesk-DBus .NET binding for Windows. Again, it
> appears this was originally intended to be built under Linux using Mono but
> I managed to hack the build environment to build it under Windows. The end
> result was a .NET assembly under Windows. I next installed IronPython and
> GTK# (the .NET port of GTK) and actually got an application up and running
> under Windows. Unfortunately, I cannot figure out how to receive signals
> using NDesk-DBus/IronPython and it only appears to support synchronous
> messaging and only a single return parameter. Also, it requires me to define
> D-Bus proxy interfaces using C# (and compile them into assemblies/DLLs) that
> mirror the D-Bus services I’d like to call. Finally, it doesn’t appear this
> project is being maintained or updated since ~2006. So, without examples
> (none which I could find for a NDesk/IronPython combination), this approach
> appeared to be a dead-end.

Both you and Avery were given the impression that there hasn't been
development since 2006, whereas you can see from that things are quite active:

2009-03-14	Alp Toker	Provide a way to get the signature of a Type in the...
2009-03-13	Alp Toker	Support reading complex variants via System.Convert
2009-03-13	Alp Toker	Test skipping over complex variant values

The release archive ( has
regular releases from 2006 to 2008 (with git head carrying the latest
changes that haven't yet been released).

This leads me to guess that you might be getting managed D-Bus from
the wrong site or a stale GitHub clone. Can you let me know where
you've been getting the old code so we can ask them to sync up?

We've set up http git access now which might help if your company
blocks ordinary git:

git clone

Some of the recent managed D-Bus fixes include full support for
arbitrarily complex variants, full SASL with the ability to support
SSL encryption, a fully managed D-Bus daemon and a comprehensive NUnit
test suite.

To import and export method calls with multiple return values, we use
CLR 'out' parameters:

[NDesk.DBus.Interface ("org.ndesk.Demo")]
public interface IDemo
  void FrobData (out int myInt, out string myString);

IronPython will return multiple out parameter results from calls to
the above method as a Python tuple, which seems a natural way to
handle them.

Regarding asynchronous messaging, internally, managed D-Bus is layered
to fully support asynchronous operation, though the public API exposes
a synchronous-style interface for simplicity. Asynchronous calls can
be achieved using multiple threads or creating a delegate and using
BeginInvoke -- managed D-Bus is fully thread safe and parallelises
calls that are made on different threads for you. There may be a more
elegant / non-threaded way to expose this to dynamic languages, or
using LINQ / PLINQ -- suggestions welcome. BeginInvoke is already one
of the conventions for async IO in the CLR itself, for example.

Regarding syntactic sugar and automation for dynamic DLR languages
like IronPython and IronRuby, there is some dynamic support for DLR
languages though it's not included in a standard NDesk D-Bus build. To
try it out, pull the latest git head from
and add TypeImplementer.cs to the Makefile (or VS project).

This will add a new overload of the Bus.GetObject() method that does
not require an interface to be specified. When called with a bus name
and object path, it dynamically inspects the remote object, generates
semi-anonymous interfaces inferred from the introspection data and
returns a System.Object implementing those interfaces. The result is
that you can use many D-Bus services with just a couple of lines of
code with IronPython and NDesk D-Bus.

Managed D-Bus has been stable and tested on Windows .NET for over a
year, though we could add Visual Studio project files to make that
more obvious.

Your use case is definitely part of our goal and we should aim to
update the documentation (
with specific examples using IronPython and Visual Studio, and to add
IronPython-based unit tests.

the browser experts

More information about the dbus mailing list