[vlc-devel] libvlc on NuGet

Jeremy Vignelles jeremy.vignelles at dev3i.fr
Thu Aug 17 10:04:19 CEST 2017

Hi Damien, 

Thanks for your answer. To clarify a little, I am not the one who created the library. I just found it one or two month ago and I am trying to push some evolutions into it (example: I added a way to register a log callback in your .net project rather than printing them to the console or to a file.)

One of my concerns is about the `lib` folder that is integrated in the repository and shouldn't be there. See the discussion (monologue) here : https://github.com/ZeBobo5/Vlc.DotNet/issues/288
In short : binary files should not be in the repository and we should find another way.

> I think including vlc in nuget is a bad idea : it will make a really big
package, if you plan to include both x86 and x64.
> Also how to choose which version of vlc to use, and about updates. What
about deployment of many applications on same computer, there would be many
duplicated files on disk...

I think there are two conceptions of software deployment:
- Install things globally:
Upon installation of your software, you must ensure that the required components are installed, at the right version, and that nothing will mess up with the libraries you are depending on. The application I'm working on comes from that world : COM components, codecs that needs to be installed, ActiveX ... in the end of the day, you would have run like 10 different setups (in order) (Or made a big installer that takes care of this for you). We had issues figuring out which piece of software interacts with what.

If you want to use the globally installed Vlc with Vlc.DotNet, you can, just provide the path to Vlc.

- Install things locally:
I see several advandages of this method (used by node.js for example, and that's also the way NuGet works):
   - You have the control of which version of the library you redistribute
   - No interaction with the rest of the system
   - Put files in a folder and run, no complicated setups, no installation path to remember and no need to have admin rights on computer.

For my application, I'd like that kind of installation, and push updates of libvlc with my app. It is possible to do so in Vlc.DotNet by downloading your own vlc release from videolan and specify that path in Vlc.DotNet. If you want to have libvlc in a subfolder of your .exe, you will need an extra build step to copy files to the output directory.

I'd like to be able, if I want, to download a package named "VideoLan.LibVlc.Windows.X86" and/or "VideoLan.LibVlc.Windows.X64" (both are independant), and all the project configuration/copy to output folder is handled through NuGet.

By the way, this is how it works for CeFSharp, to make a chrome in a .net app : https://www.nuget.org/packages/cef.redist.x64/ and https://www.nuget.org/packages/cef.redist.x86/

- Vlc.DotNet should not depend on any libvlc package, the installation is optional
- You may install libvlc manually if you want, or install VLC globally and use those libs
- At least 2 NuGet packages need to be created (windows x86 / x64)

> Making devs for other platforms is a really good idea. You can develop
targeting netstandard1.4 I think, netstandard2.0. And you should be anycpu,
not x86 or x64.

Vlc.DotNet is now AnyCPU. I plan to add netstandard support for Vlc.DotNet.Core and Vlc.DotNet.Core.Interops.

> Also, you will have to rewrite your code to remove windows specific APIs,
or add a way to properly detect platform and do the stuff accordingly.

I had a Proof of Concept that was able to load Vlc libraries on linux (mono). It doesn't require that much rework. https://docs.microsoft.com/fr-fr/dotnet/api/system.runtime.interopservices.runtimeinformation?view=netcore-2.0 will probably help

> For example, I would be happy to use your lib on Linux arm (raspberry pi)
with dotnet core 2.0.

Yeah, me too. Unfortunately, VLC in a window on linux will probably have to wait a little since I don't know any .net core GUI framework...

> And as bonus points, you may start adding vlc 3 APIs (from vlc git).

Looks like someone already had that idea : https://github.com/ZeBobo5/Vlc.DotNet/pull/207
Do you have any API that you would like being ported? Do you know how I could detect the libvlc API version? (I didn't searched, I admit).

More information about the vlc-devel mailing list