Well it works fine, DllMap make the trick.
--------------------------------------------------
From: <arnaud.champion(a)devatom.fr>
Sent: Wednesday, October 20, 2010 12:13 PM
To: "Matthias Bolte" <matthias.bolte(a)googlemail.com>
Cc: <libvir-list(a)redhat.com>
Subject: Re: [libvirt] [PATCH] Change/create solution and project for
VisualStudio and MonoDevelop for C# bindings
Impeccable ;)
--------------------------------------------------
From: "Matthias Bolte" <matthias.bolte(a)googlemail.com>
Sent: Wednesday, October 20, 2010 12:12 PM
To: <arnaud.champion(a)devatom.fr>
Cc: <libvir-list(a)redhat.com>
Subject: Re: [libvirt] [PATCH] Change/create solution and project for
Visual Studio and MonoDevelop for C# bindings
> 2010/10/20 <arnaud.champion(a)devatom.fr>:
>> 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(a)googlemail.com>
>> Sent: Tuesday, October 19, 2010 6:38 PM
>> To: <arnaud.champion(a)devatom.fr>
>> Cc: <libvir-list(a)redhat.com>
>> Subject: Re: [libvirt] [PATCH] Change/create solution and project for
>> Visual
>> Studio and MonoDevelop for C# bindings
>>
>>> 2010/10/19 <arnaud.champion(a)devatom.fr>:
>>>>
>>>> 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(a)redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list