New version is out: 0.23.1 fix a bug in which the bus daemon wouldn't recognize when a service owner exited. unregister a callback in the mono bindings so that unmanaged code wouldn't callback into a garbage collected delegate and crash
Created attachment 51092 [details] dbus-0.23.1.ebuild This ebuild works fine for me.
foser, can you please add mono support again. This would make the beagle stuff a lot more easier to do...please! :) kai
there's a assembly versioning problem with the 0.23 -> 0.23.1 transition. Apps built vs the 0.23 dotnet dll's won't work/can't find the 0.23.1 dll's . According to the mono ppl this should work (major/minor stays the same), but apperantly it doesn't. This is something which needs to be figured out first, what exactly the problem is, where it is (mono/dbus/dbus-using-mono-app) and how to resolve ofcourse. eg. Tomboy should expose this problem (only app in the tree which uses the mono dbus bindings if available).
AFAICT assembly version mapping has only been in mono since Tuesday last: http://svn.myrealbox.com/viewcvs/trunk/mono/mono/metadata/assembly.c?rev=40291&r1=39800&r2=40291 is the colourdiff showing when mono_assembly_remap_version is implemented. So assembly mapping will work in the next mono release, hopefully.
Wait, that only works for system assemblies. It seems in the current code there is no support for remapping build/revision generically. Perhaps we need a revdep-rebuild for mono programs? I've written the start of one but it's ugly (uses mono internals rather too much). As the PE format is fixed writing one to directly parse exe files shouldn't be too tricky.
I asked around a bit and the general consensus seemed to be that it should be working already and I believe it is, you can easily update say your gnome-sharp stuff and not rebuild apps depping on it. My hunch is somehow the added micro .1 for the build nr. is problematic.
As well as the issues described here I think we should also wait for 0.23.2 as 0.23.1 contains an annoying bug: http://lists.freedesktop.org/archives/dbus/2005-February/002198.html
Re comment 6: Yes, but those retain the same major/minor *and* build/revision. AFAICT the current Mono method to resolve assembly references in the GAC is to construct the expected path to the assembly and only then try to load it. So if the assembly reference is to dbus-sharp/0.23.0.0__foo and the dll is now in dbus-sharp/0.23.1.0__foo you get ENOENT (which is why you get "System error: No such file or directory" as the error) and the assembly fails to load. In mono/metadata/metadata.c: mono_assembly_load_from_gac(): version = g_strdup_printf ("%d.%d.%d.%d_%s_%s", aname->major, aname->minor, aname->build, aname->revision, culture, aname->public_key_token); subpath = g_build_path (G_DIR_SEPARATOR_S, name, version, filename, NULL); ... fullpath = g_build_path (G_DIR_SEPARATOR_S, mono_assembly_getrootdir (), "mono", "gac", subpath, NULL); result = mono_assembly_open (fullpath, status); There is no attempt to remap to assemblies with different build/revision except for a list of preloaded system dlls (and that only in recent CVS).
OK, seems .NET has a mechanism for this, assembly version policy binding redirects - see http://samples.gotdotnet.com/quickstart/howto/doc/version.aspx and http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconassemblyversionredirection.asp However it seems Mono doesn't implement this. Annoying. http://bugzilla.ximian.com/show_bug.cgi?id=30097 seems partway relevant but Miguel WONTFIX'd it - I wonder why?
dbus 0.23.2 is out Change Log: * fix a bug in the mono bindings in which non-deterministic class finalization could cause dbus errors at application shutdown * a ton of thread locking-related bugs fixed * enforce that apps speaking on the session bus are the same user as the bus itself
*** Bug 82656 has been marked as a duplicate of this bug. ***
added 0.23.2 with a version override for the mono bindings, hackish but the micro nr. being interpreted as buildnr isn't handled by mono like it should.
