This site relies heavily on Javascript. You should enable it if you want the full experience. Learn more.

NuGet development packages

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.

All packages prefixed with VVVV. are intended to be used for plugin development only and will therefor install all references in a way so that they won't get copied to the output folder (Copy Local set to false). This was done to avoid assembly conflicts at runtime.

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.

When installing the packages it might happen that the IDE won't find the referenced assemblies immediately (putting a warning sign on it, or not even showing them). In such a case ensure that the solution build configuration is setup properly (most of the VVVV.* packages are only available for x86 and x64, not AnyCPU) and/or reload the whole solution.

As of version 34.101 the packages should work in AnyCPU - for details see here

EDIT:
As of beta35 the official vvvv packages on nuget.org contain the AnyCPU configuration. no need for 'pre-release' setting or special nuget server anymore, unless you need features that are only available in the current alpha releases.

Elias, Thursday, Nov 28th 2013 Digg | Tweet | Delicious 18 comments

u7angel 29/11/2013 - 00:01

awesome,
and what about git and pushing stuff to the addonpack repo once its finished ?

Elias 29/11/2013 - 15:38

well in case yur plugin will end up in the addonpack, the process is still like described here vvvv sdk.

alg 29/11/2013 - 15:39

Next step is to allow people to submit they own packages to vvvv nuget server, so we can implement contributions package manager. I have a prototype of nuget wrapper for local packages, but delayed it until i can find a proper hosting solution, looks like this is it.

u7angel 01/12/2013 - 19:41

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...

u7angel 01/12/2013 - 19:55

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 ? :)

sebl 02/12/2013 - 18:40

top!

would be cool to have VVVV.NODES also as a nuget-package (as it's needed by the imagepack)

velcrome 17/12/2013 - 13:10

+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

Elias 17/12/2013 - 15:18

@velcrome: the daily builds are marked as pre-release packages. by default visual studio shows you only the stable packages (which is 31.3.1 for now). see this link how to change that.

velcrome 17/12/2013 - 19:58

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)

PM> get-package -listavailable

this should show you the most recent stable relases

PM> install-package vvvv.plugininterfaces

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.

microdee 25/11/2015 - 21:37

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

{
    "PackageName" : "something",
    "vvvversion" : "50 alpha 34.101",
    "Addonpack" : true,
    "Dependencies" : [
        "/* url to a git repo */"
    ],
    "Folder" : [
        {
            "Source" : "/folder/on/github", 
            "Destination" : "%VVVV%/packs"
        }
    ],
    "File" : [
        {
            "Source" : "/folder/on/github/file.txt", 
            "Destination" : "%VVVV%/packs/something/file.txt"
        }
    ],
    "ShellExecute" : "some command"
}

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

joreg 25/11/2015 - 22:23

@microdee before you dive into this just to let you know: we've got something in the works that we're hoping to release soon (<=few weeks). you may want to see that first..

microdee 25/11/2015 - 22:56

alright I'm looking forward to that then ;) I'm doing this for my packs anyway and switch over to your system when it will get released

velcrome 04/11/2016 - 01:53

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?

Elias 08/11/2016 - 13:33

It could but I don't see why. What's wrong with http://teamcity.vvvv.org/guestAuth/app/nuget/v1/FeedService.svc/ ?

microdee 09/11/2016 - 02:40

elias: it makes automatic building vvvv plugins for alpha a nightmare. it would make much more sense to publish beta libraries as release and alpha libraries as pre-release on nuget.org. also restoring packages might not work from custom sources

velcrome 31/01/2017 - 07:47

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?

Elias 31/01/2017 - 16:42

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

<packageSources>
    <add key="vvvv package source" value="http://teamcity.vvvv.org/guestAuth/app/nuget/v1/FeedService.svc/" />
  </packageSources>

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 ;)

velcrome 31/01/2017 - 17:41

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.

NuGet development packages

Shoutbox