NuGet packages install path problem and solutions

vvvv gamma general
1

During the Turning a .NET library into a VL library workshop I encountered a problem following the suggested workflow for installing NuGets for use with VL. This was caused by me having specified a repositoryPath in the User nuget.config. The result was that when running nuget install on the commandline after Quadmenu > Manage Nugets > Commandline the package was installed to the repository specified in my nuget.config and therefore not available in Gamma.

Solutions if you have NuGet configured to use a custom package repository which then will be used as default when running nuget:

  1. add -OutputDirectory option when invoking nuget, for example:
    Quadmenu > Manage Nugets > Commandline and then in the commandline run: nuget install SomeCoolNugetPackage -OutputDirectory . (see NuGet cli-reference):
  2. Put the following nuget.config in the gamma nuget folder (path revelead by:Quadmenu > Manage Nugets > Show Installed)
<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <config>
    <add key="repositoryPath" value="." />
  </config>
</configuration>

For information about NuGet config file look here.
Where you’ll commonly find NuGet config files can be read here.

Maybe this information could be edited and go into the gray book?

Possibly gamma could ship with a nuget.config in the package repo dir used by gamma but not sure if that’s a good idea or not.

2

Thanks a lot for this information. We’re moving to a newer nuget API internally, which also means that packages will get restored automatically in the future - with restore I mean that when opening a VL document all needed packages will be installed. That change will make those nuget folder we’re currently using obsolete because the new nuget API uses one global package folder and references into it directly.

2 Likes
3

Do you move to .net core, or .net? Or on .net stay standard for a while?

4

Well .net standard is the way to go for any library as it’s implemented by all .net implementations like .net framework, .net core, mono etc.
For the entry points (like our editor, or the patch one can export) we want to move to .net core (= future .net5) of course.

5

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.