How to release a pack

digitalwannabe · October 14, 2016, 7:44pm

is there any further info on releasing a pack somewhere?

all i can find is the info from the changelog of beta30 where it says:

added basic support for future packs:
add packs/PACKNAME/core to assembly search path
add packs/PACKNAME/factories to mef container catalog on startup
add packs/PACKNAME/nodes to node search path

now while vvvv finds plugins within packs/myPack/nodes/plugins it won’t find the native dll which these plugins call, which I have put into packs/myPack/core. When I copy my native dll next to vvvv.exe everything works fine (as expected), and funnily enough it works when i move my dll to dx11/core, which makes me believe now there’s something else which needs to be done to add packs/myPack/core to the search path?

thanks

microdee · October 14, 2016, 7:52pm

first use vpm! yeah!
but more importantly if .NET library A is loaded already in a .NET application .NET library B which depends on A can use A without the need for copying the DLL’s around. So if your library depends on vux’s DX11 and that is already loaded from somewhere in vvvv you don’t have to include it in your own pack.
But you don’t have to include any dependencies in your pack if you manage the dependencies with vpm ;)

tonfilm · October 14, 2016, 9:59pm

hello,

the current vvvv version does not look for native dlls in the packs folder.

but the current alpha does. the policy for native dll’s is the following:

for 64bit vvvv:
/packs/packname/core
/packs/packname/core/x64

for 32bit vvvv:
/packs/packname/core
/packs/packname/core/x86

if you place them there they will be found, but you need to use the current alpha.

this is especially cool, because all managed .NET dlls can be AnyCPU and you just place the native dlls in the respective x64 and x86 folder and users only need to download on pack for both platforms.

for older vvvv versions the developer needs to add the paths on its own… this is what vux did in dx11 and the reason why its found if you place it there.

sorry for that inconvenience…

digitalwannabe · October 15, 2016, 3:33pm

@microdee: hehe, i know i know, vpm is on top of my list to check out, but i thought it’s not a bad idea to get a pack done at all first ;)

@tonfilm: excellent, this also answers my next question on anyCPU and platform specific native assemblies :) thanks! And to be clear, your code here

github.com

tebjan/VVVV.OpenVR/blob/master/src/VVVV.OpenVR.Core/Core/OpenVRManager.cs

using System;
using System.Collections.Generic;
using System.IO;
using System.Linq;
using System.Reflection;
using System.Runtime.InteropServices;
using System.Text;
using System.Threading.Tasks;
using Valve.VR;
using VVVV.Utils.VMath;

namespace VVVV.Nodes.ValveOpenVR
{
    public static class OpenVRManager
    {
        public static CVRSystem System
        {
            get;
            private set;
        }

This file has been truncated. show original

works also in beta because openvr_api.dll is a managed dll?

tonfilm · October 15, 2016, 5:15pm

openvr_api.dll is a native c++ dll, so that piece of code does custom loading for native DLLs. i have also used it in the VVVV.Audio pack. you can use it until the new beta is out, then it can be removed if you don’t need backwards compatibility.

digitalwannabe · October 15, 2016, 6:08pm

hm ok strange, I’ve tried that before my initial post and it didn’t work for me…but i’m fine with the alpha solution for now, tried it already and works fine! thanks a lot!

joreg · October 16, 2016, 4:40pm

i put all the info here how to release a pack

digitalwannabe · October 16, 2016, 5:06pm

great, thanks!