SDK doesn't find/use bundled library-packs when additional NuGet sources are specified.

[tmds]

The .NET installation comes with a bundled FSharp.Core package that lives at: ./sdk/<version>/FSharp/library-packs/FSharp.Core.<version>.nupkg.

This package is NOT found when a user specifies RestoreAdditionalProjectSources.

This behavior results in restore errors with source-built SDKs (for versions that are not yet published on nuget.org), and causes the SDK to use binary assets from nuget.org instead of source-built assets bundled with the SDK.

Reproducer (with source-built SDK for upcoming 9.0.100):

rm -rf ~/.nuget
dotnet new console --no-restore -o console --language f#
cd console
dotnet restore console.fsproj /p:RestoreAdditionalProjectSources=file:///tmp

Error:

    /tmp/console/console.fsproj : error NU1102: 
      Unable to find package FSharp.Core with version (>= 9.0.100)
        - Found 99 version(s) in nuget.org [ Nearest version: 9.0.100-beta.24466.6 ]
        - Found 0 version(s) in /tmp

Expected behavior:

The library-packs folder under /sdk/<version>/FSharp/library-packs/ should be used also when RestoreAdditionalProjectSources is set.

cc @baronfel @MichaelSimons @omajid @Swapnali911 @Vishwanatha-HD

[tmds]

The issue also affects the $DOTNET_ROOT/library-packs directory.

For NativeAOT with the bundled ILCompiler:

$ dotnet restore /p:RestoreAdditionalProjectSources=file:///tmp
    /tmp/console/console.csproj : error NU1102: 
      Unable to find package Microsoft.DotNet.ILCompiler with version (>= 9.0.0)
        - Found 56 version(s) in nuget.org [ Nearest version: 9.0.0-rc.2.24473.5 ]
        - Found 0 version(s) in /tmp
    /tmp/console/console.csproj : error NU1102: 
      Unable to find package Microsoft.NET.ILLink.Tasks with version (>= 9.0.0)
        - Found 34 version(s) in nuget.org [ Nearest version: 9.0.0-rc.2.24473.5 ]
        - Found 0 version(s) in /tmp

Restore failed with 2 error(s) in 4.5s

vs

$ dotnet restore                                               
Restore complete (3.7s)

Build succeeded in 5.0s

[tmds]

The functional impact of this issue is limited because all nuget files we currently include with the source-build SDK are also shipped by Microsoft through nuget.org.

The issue should still be fixed because it nullifies the why these packages are included with the SDK: use source-built packages (source-built SDK), use bundled F# (source-built and Microsoft-built SDK).

[baronfel]

That's going to be hard because by setting RestoreAdditionalProjectSources at the command line you've pinned the value of that property and it can no longer be changed/updated by MSBuild logic run during the build. The property is used directly my the NuGet targets. This is a common quasi-anti-pattern - it's like we need some other property to set so that the real property doesn't get unfortunately pinned.

[tmds]

it's like we need some other property to set so that the real property doesn't get unfortunately pinned.

Yes, to fix this we need a separate (internal) property that the SDK can use to bring these library-packs directories to the NuGet restore operation.

[dotnet-policy-service]

Thanks for creating this issue! We believe this issue is related to NuGet tooling, which is maintained by the NuGet team. Thus, we closed this one and encourage you to raise this issue in the NuGet repository instead. Don’t forget to check out NuGet’s contributing guide before submitting an issue!

If you believe this issue was closed out of error, please comment to let us know.

Happy Coding!

[tmds]

If you believe this issue was closed out of error, please comment to let us know.

@baronfel is this something you triggered? If not, can you re-open the issue?

[baronfel]

No, it's a bot that operates on any issue with the 'Area-NuGet' label 😡