@josesimoes it's rather challenging to test without a working SDK, but a quick test of packing a custom nuspec created what I expected in the dependency groups, so I think & hope that both restore and pack will work once this is merged and ships.

@zivkan all right!!! Happy to test with my initial SDK version.
When/how can I get this in a usable tool? 😁

I wished you asked on any other day. Our configure.ps1 script uses dotnet-install.ps1 to install a .NET SDK locally for our dotnet.integration.tests project, but a change in the last 24 hours appears to have broken our build. There's a revert PR, but until it's merged and published to the appropriate web server, our script won't run unmodified. But we only need it for this one test project, so you can comment out the anything related to installing .NET SDKs in our configure.ps1 and/or build/common.ps1 to work around the issue.

If you're on Windows, it should be 1. clone our repo, 2. run configure.ps1, 3. run build.ps1, but you probably want .\build.ps1 -SkipUnitTests to save yourself a little time.

Assuming you need the .NET 5/Core build of NuGet.Frameworks.dll, I don't think it checks strong name keys. If you're running on .NET Framework, then you'll need to either run build.ps1 once, or dig into the scripts to see how it sets our strong name keys to be ignored (I don't know why it does this on build.ps1 instead of configure.ps1`. Anyway, this might be a workaround given that dotnet-install.ps1 is broken at the moment:

git clone https://github.com/NuGet/NuGet.Client
git switch dev-zivkan-nanoFramework
git submodule init
git submodule update
dotnet build src/NuGet.Core/NuGet.Frameworks

if dotnet build fails for some reason, try opening Visual Studio Developer PowerShell and run msbuild -restore -v:m src/NuGet.Core/NuGet.Frameworks. That might have more luck, but I think that's only needed for our code in src/NuGet.Clients, I'd expect everything under src/NuGet.Core to build with the dotnet cli.

hopefully this builds NuGet.Frameworks.dll, which you can then copy from artifacts/NuGet.Frameworks/bin/Debug/netstandard2.0/NuGet.Frameworks.dll and overwrite that same file in your SDK.

@nkolev92 local build successful and I have the NuGet.Frameworks.dll!
May sound like a dumb question but... where is supposed to be my SDK that I have to replace that DLL? 🤔

@josesimoes

That's a very valid question :)

I'd download a custom version of the SDK and put it literally anywhere. You can use dotnet --info to tell what SDK is being used.

And just copy NuGet.Frameworks in it, in a similar way like @zivkan shared.

You can use this script (keep in mind, it uses some defaults such as Configuration) that helps you copy all the built nuget files,

Nikolche's comments are about the .NET SDK, not your own .NET nanoFramework SDK. The principal is go to the directory for the .NET SDK you want to use, then in the sdk/<version>/ folder there will be NuGet.Frameworks.dll, that you replace. You can download a zip of the .NET SDK from get.dot.net/, or a nightly build from github.com/dotnet/installer, and unzip it anywhere you like. If you're feeling brave, you can technically even replace it in your system installed .NET SDK, but I don't recommend that at all, and it will put you into an unsupported configuration that will be very difficult to diagnose if it causes problems.

I don't know how any SDK that adds target platforms that the .NET SDK doesn't support is supposed to work, so if the above doesn't help, I'm really not sure. The goal is just to replace the NuGet.Frameworks.dll in the .NET SDK that is used when your .NET nanoFramework SDK is used build a nano framework project.

oh I totally misread that, thanks for clarifying it @zivkan.

Adding to what Andy said, I don't think your SDK would need to depend on NuGet.Framework, it should only rely on the msbuild logic.

Reporting back my testing on this.

Following the instructions above:

1. Successfully build NuGet Client
2. Installed preview .NET SDK 6.0.200-preview.22063.5
3. Run Add-NuGetToCLI -sdkLocation 'C:\Program Files\dotnet\sdk\6.0.200-preview.22063.5'

Using the WIP nanoFramework SDK on a test project with that sdk I get the following (using csproj):

And I'm also able to pack using nfproj format:

Still need to tackle a few issues with the build tasks but it does look VERY promising! 🥳 🚀

Thank you soo much @zivkan and @nkolev92 for helping make this possible and, of course, for the guidance provided. 😃

I can see that this is on the current sprint. Just wanted to ask if there is any expected date to see it in a preview SDK? Thanks.

It'll definitely be in the 6.0.300 SDK. Almost certainly in the first public preview, but it depends when the preview ships and when the .NET SDK set up their subscriptions to the .NET Engineering team's dependency flow orchestration system (Meastro/darc). 6.0.2xx is too close to release so now there's a high bar to allow new changes, so I just don't know if they'll accept this new TFM, even though I'd say the risk is very low.

After an appropriate version of NuGet is inserted into the .NET SDK, it'll be available in their "nightly builds", so it won't be necessary to wait until the public preview. Once they create a 6.0.3xx branch, this will be the file that defines all the .NET SDK's dependencies: https://github.com/dotnet/sdk/blob/release/6.03xx/eng/Versions.props

Search for NuGet, and as soon as NuGet's version number is 6.2.0-*, then the SDK will contain the appropriate version of NuGet.

It's available!! 🤩