Migrate all samples to SDK-style projects#463
Closed
danielmeza wants to merge 6 commits into
Closed
Conversation
Phase 1 samples pilot for the SDK-style migration. Converts two Beginner samples from the legacy .nfproj project system to SDK-style projects and verifies they build from the CLI against the official nanoFramework.NET.Sdk. - 1-BlinkLed.csproj and 2-Button.csproj: <Project Sdk="nanoFramework.NET.Sdk">, netnano1.0, with PackageReference to nanoFramework.CoreLibrary 2.0.0-preview.52, nanoFramework.Runtime.Events 2.0.1, nanoFramework.System.Device.Gpio 2.0.0-preview.18. - Removed each sample's .nfproj, packages.config, and Properties/AssemblyInfo.cs. - Beginner.sln: the two converted entries use the SDK-style C# CPS project-type GUID and .csproj paths; the other six samples remain legacy .nfproj (coexistence). - Added a dev-local build harness (global.json pinning the SDK, NuGet.Config with a local feed for the unpublished SDK build). Remove the local feed once the SDK ships to nuget.org. dotnet build produces BlinkLed.pe / Button.pe with PE magic NFMRK2 (v2); the full assembly graph restores natively as v2. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Validates that SDK-style nanoFramework projects work with NuGet Central Package Management. Adds samples/Beginner/Directory.Packages.props (ManagePackageVersionsCentrally=true) with the v2 package versions, and removes the per-project versions from the PackageReference items. No NU1008: the SDK's auto-injected MetadataProcessor PackageReference is IsImplicitlyDefined, which CPM exempts, so the nano SDK is CPM-compatible without changes. Both samples build and emit NFMRK2. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…orm bulk migration CPM was validated in isolation (test); the bulk converter emits versioned PackageReferences, so keep the whole repo uniformly versioned. Repo-wide CPM (central props + versionless) is a possible follow-up. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Convert every sample from the legacy .nfproj project system to SDK-style <Project Sdk="nanoFramework.NET.Sdk"> (netnano1.0, PackageReference), and retarget the solutions, using the NanoMigrate tool (nanoFramework.Sdk tools/NanoMigrate). - 153 projects converted across 111 solutions; packages.config + generated AssemblyInfo removed; .sln entries retargeted (project-type GUID -> SDK CPS GUID, .nfproj -> .csproj). - PackageReference versions taken from packages.config; native-stub libraries keep their AssemblyInfo.cs (AssemblyNativeVersion) with GenerateAssemblyInfo=false; resx and shared-project samples handled (no duplicate items, .projitems imports preserved). - Spot-built across shapes (app, resx, many-package) — all build; output PE is NFMRK2 (a few emit NFMRK1 where the sample still references a v1 CoreLibrary). A handful of projects are intentionally not nano SDK-style (desktop .NET Framework test helpers) and a few have pre-existing issues (package-version conflicts, a missing dependency, a bin\ HintPath sibling reference) noted during migration. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- 1-Wire/OneWire.TestApp: add the missing nanoFramework.Hardware.Esp32 PackageReference (Program.cs uses it; it was absent from the legacy packages.config, so the legacy build would have failed too). - Interop/test-application: reference the interop stub library as a ProjectReference (the legacy .nfproj used a bin\ HintPath, which the converter intentionally does not turn into a project reference). Both build SDK-style. (Base64Test's build gap is fixed separately by the SDK now defining NANOFRAMEWORK_1_0.) Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
Important Review skippedToo many files! This PR contains 300 files, which is 150 over the limit of 150. To get a review, narrow the scope: ⚙️ Run configurationConfiguration used: Repository: nanoframework/coderabbit/.coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (300)
You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
This was referenced Jun 16, 2026
Sender.csproj is an orphaned, empty project (no packages, no own source) converted from a stray Sender.nfproj that was never referenced by Amqp.Samples.sln. It collided with the real Azure-ServiceBus-Sender.csproj on the default source glob. The two real AMQP apps still need a coordinated package modernization (pre-existing version rot + Program.cs uses System.Device.Wifi / NetworkHelper while the package refs are the deprecated Windows.Devices.Wifi / missing the helper) — sample maintenance, not a migration defect. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Author
|
Closing in favor of a fresh migration: re-running the full sample migration with the improved NanoMigrate tooling (SolutionPersistence-based .sln/.slnx retargeting, build-verify/rollback/clean, vertical-slice Core). A new PR will replace this. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
.nfprojproject system to SDK-style<Project Sdk="nanoFramework.NET.Sdk">projects targetingnetnano1.0, usingPackageReferenceinstead of
packages.config.the SDK C#/CPS GUID,
.nfprojpaths to.csproj);packages.configand generatedAssemblyInfo.csare removed.dotnet nano migratetool (NanoMigrate), which derives eachPackageReferenceid and version from the project'spackages.config, folds.nuspecmetadatainto MSBuild Pack properties, preserves native-stub
AssemblyInfo.cs(withGenerateAssemblyInfo=false), and keeps shared-project (.projitems) imports.1-Wire/OneWire.TestAppgains thenanoFramework.Hardware.Esp32reference it uses (absent from the legacy
packages.config);Interop/test-applicationreferences the interop stub library via a
ProjectReference(the legacy project used abin\HintPath).
Motivation and Context
The SDK and Visual Studio extension changes are in companion PRs
(Enable VS source debugging for SDK-style projects (full PDB + F5 wiring) + target v2 (NFMRK2) nanoFramework.NET.Sdk#2 and SDK-style deploy/debug: selected-device + checksum pre-check + pluggable engine-binding seam nf-Visual-Studio-extension#929). One of
several PRs for that effort, so it intentionally does not auto-close the tracking issue.
How Has This Been Tested?
dotnet nano migrateover the whole repo: 153 projects converted, 0 review flags, 0 errors;re-running is a clean no-op (the tool is idempotent and reentrant).
.resx/resources,many-package, shared-project, interop, unit-test) with
dotnet buildagainst the SDK — all build;app output PE magic is
NFMRK2.Types of changes
Checklist:
🤖 Generated with Claude Code