today i tried to add vvvv.plugininterfaces with nuget. #Dev (b5) tells me that i need a project that is targeting .net framework 4.5 - if i do so i can add vvvv.plugininterfaces via the package manager - it automaically add vvvv.core and vvvv.utils to my project references which is really nice. But vvvv.plugininterfaces itself has only a build directory for .net 4.0 - it does not appear in the project references.
edit: if i add the 4.0 version of plugininterface´s dll manually to the project references it works as expected.
i also had some problems with the nuget recently, mostly when updating to a new version. it seems to me that sometimes it does not update the filename in the csproj, which forced me to do all the changes manually and defeating the purpose of nuget automatisation.
maybe this has something to do with the way it is linked as a of a project, instead as a ?
At the beginning of vvvv’s nuget feed you had both stable and alpha releases to pick from, for some time now you only have your rolling release. Most of the work I am doing is with the beta (currently 31.2x64), but there is no way to do that with nuget any more. Also if I do not update the references, a fresh clone from git will not pull the packages if the feed has been updated- old versions (that are referenced in the project) are never offered and hence a build or an update might fail.
Would it be possible to reintroduce stable versions that remain indefinitely in your feed? I would then update my libs in my projects only with the release of a new beta.
as soon as we release the new beta, stable packages will be available for it. so this should address the most common case that one wants to write plugins against the latest beta release.
the other case, where one wants to have the latest development packages (pre-release packages in nuget) seems a little broken right now, as the build server creates packages for each feature branch we have internally (like in your case velcrome develop-avalon-edit) and the UI of the nuget package-manager in sharp develop and also visual studio i think won’t let you choose between say “31.7.0-develop” and “31.7.0-develop-avalon-edit”, but instead simply picks the latest one sorted by version followed by the string after the version.
you can see that there’re more available in our nuget feed if you open it with the nuget package explorer.
the most simple solution would probably be to skip creating packages for feature branches and only stick with our main develop branch. i’ll tell you once i’ve sorted that out.
the other described issue that the reference to VVVV.PluginInterfaces won’t show up in the UI seems to be only present in sharp develop. the problem is that as long as our core packages depend on slimdx, we can’t set our projects to AnyCPU, and instead have to keep conditional references depending on the set build platform. this scenario is not properly implemented in nuget so i’ve followed a little different path nuget introduced in the 2.5 release by using the package-name.props and package-name.targets files nuget will add imports to in the project referencing package-name. you’ll see in case of VVVV.PluginInterfaces for example that the actual reference of the assembly is done in the VVVV.PluginInterfaces.targets file, imported at the end of your project file. visual studio and more importantly msbuild seem to deal with that just fine, the UI of sharp develop doesn’t. :/
so as long as you’ve set the build platform to either x86 or x64 in sharp develop the solution should build just fine, despite the reference to VVVV.PluginInterfaces not showing up.