Change proposal: NugetPackageManager restore functionality

AndrewK · July 18, 2024, 2:26pm

Time didn’t allow, so no progress, but found also a potential bug/unintended behavior around this line:

open-rpa/openrpa/blob/4bdd00d59fdd3968b3d4491496bb108ffd9f0595/OpenRPA/NuGet/NuGetPackageManager.cs#L168


      
          public async Task<List<IPackageSearchMetadata>> SearchPackageVersions(string packageid, bool includePrerelease)
          {
              var ret = new List<IPackageSearchMetadata>();
              foreach (var sourceRepository in DefaultSourceRepositoryProvider.GetRepositories())
              {
                  var searchResource = await sourceRepository.GetResourceAsync<PackageMetadataResource>();
                  using (var cacheContext = new SourceCacheContext())
                  {
                      cacheContext.DirectDownload = true;
                      var metadataList = await searchResource.GetMetadataAsync(packageid, includePrerelease, true, cacheContext, NullLogger.Instance, CancellationToken.None);
                      if (metadataList.Count() > ret.Count())
                      {
                          ret = metadataList.ToList();
                      }
                  }
              }
              return ret;
          }
          public async Task<List<PackageSearchItem>> GetLocal(Project project, PackageIdentity identity)
          {
              var result = new List<PackageSearchItem>();

Since for my testing purposes I’ve put in OpenFlow just the versions I wanted, it wasn’t actually finding the package version I was expecting it to see due to (I think, can’t go to debug mode right now) a different feed having more versions of that package.

What seems to be potentially causing it is a little above the highlighted line - if I’m reading it correctly, the search uses always all feeds, regardless of which one is selected, and returns results from the one that has most versions (which might not include the version that is needed).

Truth be told, I have a working “workaround” for these issues (with the custom workflows, and adding the extension-runtime-cache), so I’m not sure if this should be pursued further, as it seems (and this might be overshooting) that most of the NugetPackageManager (including the UI bindings) would need changes.
So I’m not really sure if it’s worth it (still would be fun though, but time and so on).

I guess we could just pull in the changes related to the folder cache (so dll’s don’t lock, ergo update works as expected) and leave the rest for later?