Support Multiple Nuget Feeds

[BlythMeister]

You can set an alternative feed, but this only supports changing the feed.

It would be nice to be able to specify multiple nuget feeds.

Or, even better use the nuget.config file that projects use.

[timshepherd-academy]

I'd like to vote this one up if possible

I have a project that has packages from a internal private (Teamcity based) feed, and "public packages" from Nuget.org. The Cyclone tool keeps trying to get the Nuget packages from the internal feed - which of course fails, but then the whole process fails and the tool stops.

Publishing the internal packages to Nuget.org is not an option for us.

[Bertk]

We use CycloneDX tool with multiple NuGet feeds (also with private Azure DevOps feeds) without problems since years. We use nuget.config file for feed configuration.

Please make sure to execute a successful dotnet build before running the CycloneDX tool.

[timshepherd-academy]

@Bertk I'm curious to know the details of how you make that work 'cos I couldnt make the cyclone tool work as a build step in Teamcity or the commandline

[BlythMeister]

I think, if you have already done the build/restore steps using a standard .net cli and the obj project assets have already been created, then it works.

If your trying to use cyclone without 1st building (therefore meaning cyclone does the restore) it doesn't work.

[Bertk]

@timshepherd-academy Please also use dotnet-CycloneDX parameter -dpr|--disable-package-restore.

see also GenerateSBOM.yml

[github-actions[bot]]

This issue is stale because it has been open for 3 months with no activity.

[fbrunetgirard]

I think it doesnt read nuget.config at all , and use only the default nuget feed, you need to put additional argument like -u + credential

I have a private feed and have lot of problem even when nuget restore is disabled via -dpr It's related to https://github.com/CycloneDX/cyclonedx-dotnet/issues/603

[jwfx]

CycloneDX only seems to look for packages in the global package cache. But even after a full restore, certain packages will never be part of that cache.

One issue we ran into are fallbackpackagefolders.

Only after commenting out the fallbackpackagefolders and repopulating the global cache, the CycloneDX exceptions went away.

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <add key="DevExpress 21.2 Local" value="C:\Program Files (x86)\DevExpress 21.2\Components\System\Components\Packages" />
  </packageSources>
  <fallbackPackageFolders>
    <!--<add key="DevExpress 21.2 Local Offline Packages" value="C:\Program Files (x86)\DevExpress 21.2\Components\Offline Packages"/>-->
  </fallbackPackageFolders>
</configuration>

CycloneDX should not only honor the full restore hierarchy, e.g. via nuget.config, but also handle fallbackPackageFolders without throwing exceptions about missing packages.