Improve inner-loop testing for packages

[anangaur]

Its difficult for package authors to test their package while in development. Some context: https://twitter.com/khellang/status/1244892768717209600

Related issue, that was closed: #1821

Lets discuss possible (current/future) solutions, here.

[anangaur]

/cc: @nkolev92 @rrelyea fro NuGet
@khellang, @joacar from twitter thread

[joacar]

I'm working on a NuGet packages that integrates with MSBuild by having .targets file in build/ directory. This use case isn't covered by adding library under test the project reference way since the files won't be picked up by VS (latest 16.5). I'll outline the steps I've done to make it work

1. Add nuget.config to sample project (project used to test NuGet) and add directory where artifact will be published
2. Pack NuGet to directory in step 1.
3. Add packages to sample project using CLI (nuget.config not honored in VS) dotnet add <csproj> package <nuget> -v <version>.

So it works. Now we do some changes to our library and want to test them. Here we need to decide whether to update NuGet version or not.

Leave version intact

1. Source code changes
2. Pack NuGet

Since the version is the same, the global packages path (nuget locals global-packages --list) is unchanged and dotnet add doesn't add the newly created nuget. Solution is to remove the directory from global packages path and then add it.

Update version

1. Source code changes
2. Update NuGet version
3. Change version in referenced project

I've gone with Leave version intact and wrote a bash script to perform the steps.

#!/bin/bash

if [[ -z ${NUGET_GLOBAL_PACKAGES} ]]
then
  echo "Environment variable NUGET_GLOBAL_PACKAGES must be set"
  echo "Run 'nuget locals global-packages -list' and export value"
  exit
fi

if [[ -z $1 ]]
then
  echo "Version is required"
  exit
fi

ROOT=`pwd`

# Delete cached packages since version is most likely not changed
rm -rf ${NUGET_GLOBAL_PACKAGES}<package_directory>
# Pack new NuGet
dotnet pack -c Debug <proj> -p:RepoRoot=${ROOT}
# Add package to sample. Since pre-release version is required
dotnet add <proj> package <package> -v $1

[nkolev92]

Hey all, this ask is a duplicate of #6579.

Clearing the individual packages in the global packages folder is the best thing we have today.

An idea would be to provide some metadata on a package that we can put in a separate directory, but that mgiht get tricky from a perf perspective.

[gioce90]

Clearing the individual packages in the global packages folder is the best thing we have today.

Yes @nkolev92 , this is my same conclusion, as pointed out in #13918 and also here

[gioce90]

Hi @anangaur @joacar @nkolev92 , I’ve faced similar issues in the past when working with NuGet packages. As I mentioned here, I created a tool to address these problems.
I’ve now decided to make my solution public by releasing a package called NuJet (https://github.com/gioce90/NuJet). It enhances the inner-loop development and testing process for NuGet packages, especially in local workflows.

Feel free to check it out—I’d love to hear your feedback!