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?
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 ;)
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:
for 32bit vvvv:
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…
@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
works also in beta because openvr_api.dll is a managed dll?
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.
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!
i put all the info here how to release a pack