Open papanito opened 3 years ago
We're experiencing a similar issue. I think it should be reproduceable by adding a .NET Standard project to a classic framework solution.
It seems to work fine through the JFrog CLI and nuget.exe directly.
Hi @papanito and @jdmeer thanks for reporting the issue.
As you can see our plugin run the flowing command : nuget restore .\SC.DYN.sln -configfile C:\Users\FSBC24~1\AppData\Local\Temp\artifactory.plugin.nuget.config2078826087370724410.tmp
Please let me know what you think.
@talarian1 did you happen to try it with a solution that contained both a .NET 4.x.x project and a .NET 5.x.x project (or a .NET Standard project)?
We've uncovered a cause of this behavior. Old versions of .NET Core had the concept of a NuGet "Fallback" folder. We've found that in some situations, when restoring packages, if the package can be found in this fallback folder location, it is not put into the usual global NuGet cache. Then, when JFrog tries to find it in the cache for its own purposes, it can't find it. By simply deleting this folder (on our machines, located at c:\program files\dotnet\sdk\NuGetFallbackFolder), our builds started working again.
Describe the bug
We introduced the
rtNugetRun
into our projects as followsHowever now the build fails with the following error
Which does not make sense as the package
system.net.sockets.4.3.0
is not a dependency of the project.To Reproduce
N/A
Expected behavior
Only request packages which are part of the project
Screenshots
N/A
Versions
Additional context
Add any other context about the problem here.