[libvirt] [PATCH] Change/create solution and project for VisualStudio and MonoDevelop for C# bindings

[arnaud.champion at devatom.fr]

Well it works fine, DllMap make the trick.

--------------------------------------------------
From: <arnaud.champion at devatom.fr>
Sent: Wednesday, October 20, 2010 12:13 PM
To: "Matthias Bolte" <matthias.bolte at googlemail.com>
Cc: <libvir-list at redhat.com>
Subject: Re: [libvirt] [PATCH] Change/create solution and project for 
VisualStudio and MonoDevelop for C# bindings

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