ïImpeccable ;)
--------------------------------------------------
From: "Matthias Bolte" <matthias.bolte@xxxxxxxxxxxxxx>
Sent: Wednesday, October 20, 2010 12:12 PM
To: <arnaud.champion@xxxxxxxxxx>
Cc: <libvir-list@xxxxxxxxxx>
Subject: Re: [PATCH] Change/create solution and project for Visual
Studio and MonoDevelop for C# bindings
2010/10/20 <arnaud.champion@xxxxxxxxxx>:
The problem with DllMap, is that it works only under Mono, not under .Net
:(
Well, no problem three. You keep the [DllImport("libvirt-0.dll")] in
the code for .Net, so it works for .Net and add a DllMap that tells
Mono that it should use libvirt.so.0 on Linux instead of libvirt-0.dll
etc. I think this is exactly how DllMap is supposed to be used.
Matthias
--------------------------------------------------
From: "Matthias Bolte" <matthias.bolte@xxxxxxxxxxxxxx>
Sent: Tuesday, October 19, 2010 6:38 PM
To: <arnaud.champion@xxxxxxxxxx>
Cc: <libvir-list@xxxxxxxxxx>
Subject: Re: [PATCH] Change/create solution and project for
Visual
Studio and MonoDevelop for C# bindings
2010/10/19 <arnaud.champion@xxxxxxxxxx>:
Hi,
here are 2 patches for C# libvirt bindings.
These patches create a new solution/project couple for Visual Studio
2010
with also a sample code and a solution/project couple for MonoDevelop
with a
sample code also.
The sample code have been tested under .Net/Windows, Mono/Windows and
Mono/Linux. And it works, the sample code consist of the using au
virConnectOpenAuth and callback handling. It connect to a URI (I have
made
my tests with ESX hypervisor only) and list domains in a listbox.
So, to summarize, code work under linux or windows, the binary library
name
depends of a project directive (a kind of pragma). When the directive
WINDOWS is declared, DllImport will try to find "libvirt-0.dll" (for
windows) otherwise it looks for "libvirt.so.0" (for linux). For now, in
the
same manner, when the directive WINDOWS is declared, we find _strdup in
"msvcrt.dll" otherwise we look in "libc.so.6".
This makes the resulting binary platform dependent. I asked a friend
about this and he suggested to use Mono's dllmap feature [1]. It
allows you to stick with [DllImport("libvirt-0.dll")] in the code for
.Net and have Mono use libvirt.so.0 on Linux and libvirt.dylib on OSX.
This result in a platform independent binary regarding this issue.
[1] http://www.mono-project.com/Config_DllMap
I'm currently trying to remove strdup call by Custom Marshaling but it
seems
that .Net (or Mono anyway) doesn't allow to use custom marshaler with
structure (and we need it for virConnectCredential structure). If
anyone
had
an idea...
Regarding this issue my friend suggested to stop libvirt from taking
ownership of cred.result. We could do that by making
virConnectOpenAuth take a new VIR_CONNECT_COPY_CRED_RESULT (or
VIR_CONNECT_DONT_FREE_CRED_RESULT or VIR_CONNECT_CONST_CRED_RESULT)
flag that lets libvirt internally strdup() cred.result before passing
it to the driver. That way the C# bindings could pass a managed string
as cred.result and we don't need to Marshal.StringToHGlobalAuto() and
strdup in C# at all.
Or we could make libvirt take a custom free function to free
cred.result instead of free(). That way Marshal.FreeHGlobal could be
used or no free function at all and you pass a managed string to it.
This would probably require a new version of virConnectOpenAuth and I
consider this as too invasive.
Another possibility would be to add a public virAlloc to libvirt that
C# can use to allocate memory that can be freed using free().
Matthias
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list