When writing a plugin for vvvv the developer needs to at least add a reference to the VVVV.PluginInterfaces assembly. In order to do so there’ve been two choices up till now:
- Reference the assembly directly (e.g. from a vvvv-release)
- Reference the VVVV.PluginInterfaces project from the vvvv-sdk Both of these choices have drawbacks. Referencing directly requires the developer to update the assemblies manually with every new vvvv release, referencing the project enforced the inclusion of the whole vvvv-sdk which is quite large and sometimes tiresome to build.
Thanks to NuGet (a package manager for the windows development platform) and TeamCity (a build and NuGet server) a third choice emerged without the drawbacks mentioned above: referencing the assembly via a NuGet package.
Everytime our build server builds a new version of vvvv, it will also create a bunch of NuGet packages (VVVV.PluginInterfaces, VVVV.Utils, etc.) with the appropriate version information. When doing an alpha build those packages will be considered as a so called pre-release package by NuGet, when doing a beta build those packages will be considered as a stable release.
Now in order to create a plugin for vvvv by using NuGet, the developer has to:
- Ensure the project is targeting at least .NET Framework 4.6.1 and is configured with the platforms x86 and x64.
- Add http://teamcity.vvvv.org/guestAuth/app/nuget/v1/FeedService.svc/ as a NuGet package source in the settings of the NuGet package manager shipped with either Visual Studio or Sharp Develop.
- Select the VVVV.PluginInterfaces package and click install.
NuGet will now download and add all the necessary dependencies to the project file and whenever a new version of vvvv is available, the NuGet package manager will ask whether or not to update the installed packages.
As of version 34.101 the packages should work in AnyCPU - for details see here
Comments:
Comments are no longer accepted for this post.
51 <= few weeks.
oh the pun ;)
just an easy question: can teamcity publish the nightly on nuget.org too, in case it has new commits?
Seconded.
Anyone cloning sources, and compiling it has to manually add the teamcity server or it will not find dependencies.
Your TC server tends to be less than reliable, especially while it’s compiling.
Switching back and forth from alpha to beta is tedious.
But let’s hear your argument: what’s the rationale of having alpha dependencies on a different feed than beta dependencies?
Well simply to not spam nuget.org with thousands of packages. Also many other projects use the same policy using a private feed for daily builds. So adding just those few lines like
to a nuget.config file never seemed like that big of a hassle to me… but if you guys insist I’ll add it to my todo list ;)
Ah, cool, didn’t know this existed. Might have saved me some headaches with appveyor. This is worth mentioning in the top post while you serve private nugets!
Ofc it doesn’t fix the perf issues of vvvv’s TC server for alphas.
elias, can you give a step by step instruction on how to work on some existing code from the addonpack. let’s say the bulletphysics. can nuget be helpful to quickly get it running again ?
i tried and it gives me weird compile errors, slimdx not found, plugininterfaces not found …although nuget installed them successfully, green check.
visual studio 2013 i have…
btw. i wonder why so many cool plugins “just” end up in contributions and never get contributed to the addonpack. my guess is, the process is too complicated.
well, at least for me, i switch the dev machine all the time, re-install windows etc. and going through the 9 steps (or more) to work on some addonpack compatible stuff is just not very compelling.
isn’t there an easier way ? what about someone drops contributed plugins to the addonpack ? :)
top!
would be cool to have VVVV.NODES also as a nuget-package (as it’s needed by the imagepack)
+1 for VVVV.Nodes
i saw the last published packages are from the 27.11. and have a version of 31.3 current alphas are nightly and most current version as of now is 31.5
this is not intended, is it? because i can see no reason to prefer an outdated alpha to both a most recent alpha and the last proper beta
thanks, did not see the option.
when downgrading to a stable release I needed to go over the Package Manager Console (Tools->Library Package Manager->Console) and selecting the vvvv package source (and ofc the correct default project)
this should show you the most recent stable relases
this installs the most recent stable release of e.g. the plugin interfaces
so far so good, nuget seems to be really nice so far. i just tried myget.org, which calls itself a nuget-as-a-service-cloud-hoster. it even has a build thingy, that can grab a source from github or bitbucket and try to compile it. once you add the vvvv feed to its sources. keeps on telling me that it was successful, even though the log is long with errors…
it would be really nice if all packs for vvvv could be delivered this way, so lets see what pops up.
for vvvv we could build up a method using github api that however would require you to store binaries on github. so you would still need to search for a term and the vvvv package manager would only list repos with a specific file in it like “.v4pack” that would look something like
So vvvv would clone git temporarily copy above marked files to their place then delete the temporary clone. Also there can be a shellexecute if the pack requires any drivers or compilation. It would be also nice to have a primitive api for the vvvv site so that vvvversion there could do more than just warn you about needed version of vvvv and addonpack hmm i will actually start this today