Can't add dynamic plugin if i copy it from one machine to another

I haven’t found any bug report on that, so i decide to post it here:
So if i make a dynamic plugin on one machine i can’t easily open it to another…

hei anto,
i think you’ll have to be a bit more specific about this. what exactly are the steps that you’re trying to do and where/how exactly is it failing?

I’ve found it not possible to drag and drop into a patch, and also not appear in the node browser despite being in the plugins folder, I’ve tended to solve it by making a new one from template and copy pasting in…

hi cat, i think you have to delete everything in bin folder to make it work…
joreg, i will upload the plugin i can’t open in the eve

ok, quick update… i did double check on clean patch and i couldn’t reproduce this. Looks like problem appears on vvvv during the patch development… I will do more tests, and if anyone will have that pls try to catch tty message or log the report…

The paths in the .csproj file are relative, so if vvvv is in a different place (or x86 vs. x64, or a different version) then it will not load, and the .csproj file has to be manually edited to correct the paths.

Now you can change the vvvv folder relative paths to $(VVVV45), which makes it all portable, but annoyingly as soon as you edit and save the plugin, they get replaced with relative paths again. Hmmm, guess that should be reported as a bug…

Likewise, any other libs you use (like OpenNI, etc.) will also have relative paths in the .csproj file that will need to be manually changed if they are not in the same place.

ok, that’s sounds quite possible, i used two machines for testing where path to vvvv folder was same, but other machine had vvvv on desktop…

quick tests did’t reveal the issue tho… moving vvvv folder around doesn’t help, plugs get added in clean patch anyways…

Hi, got it again today on machine, with Cyrillic Windows.
TTY Shows absolutely nothing. Cloning template did helped, removing bin folder did’t… Closing reopen vvvv did’t worked also…Opened that plug on another machine it worked fine.
I just gave it a try after few hours and it to opened, so i decided to look for one before i removed bin folder.
This one is red on both machines…
ValueCounter.zip (17.8 KB)
Looks like removing bin folder helps, but not straight away…

I changed the ReferencePath entry in the .csproj file as follows:

<ReferencePath>$(VVVV45)\lib\core\;$(VVVV45)\lib\nodes\plugins\</ReferencePath>

and it works for me! And as long as you don’t edit and recompile the plugin, you should be able to happily copy it to other systems no matter where vvvv is located. If you do edit the plugin, you’ll need to change that line back again. (Hint: keep a copy named something like (plugin).csproj.txt to quickly copy it over.)

ValueCounter-fixed.zip (21.8 KB)

Just downloaded your zip file, extracted it and it worked :/ Any other hints about your setup?

Did you mean to say it did NOT work? I think the only way that could fail is if the VVVV45 path is wrong, or maybe you have some conflicting version of Visual Studio installed, or not all the proper runtimes. Have you run setup.exe for the vvvv you are running? Are you running the patch by double-clicking it in explorer? This is how I fix dynamic plugins between all versions of vvvv, never seen it fail before. Maybe a corrupt vvvv installation or libraries?

Try running this patch and see if you get a good path for VVVV45:

GetVVVV45.v4p (3.3 KB)

What I meant is that I downloaded antokhio’s zip file, openend it and it just worked. Which is bad, because I can’t reproduce the issue you guys are having and so I won’t be able to fix it.

If you can try another machine Elias, you have to be on 64 vvvv, in 32 it will work, since it will recompile.

@antokhio
Either I open the patch from a folder in desktop or from contibutions\plugins\ValueCounter, it shows a red node with b34.2 32bit. I have to change the ref path to get it working.

We finally found a machine here in the office where we were able to reproduce your issue. In your example the bin/Dynamic folder contains an empty assembly (no idea how it got there in the first place) which the system thought was the current one and so it didn’t came to the conclusion to recompile the project. I refined that code part, so should work now.

I don’t know how many years passed before this bugger caught… Good job!!