Description
CoreLibrary is the root of the dependency graph and a special case for the migration. An SDK-style CoreLibrary.Sdk.csproj (targeting netnano1.0) exists on the move-to-sdk branch, and the published v2 previews already restore natively against netnano1.0, but the SDK-style project is not yet the primary project for the repository. Because every other library depends on CoreLibrary, it has to be migrated and republished cleanly before (or at the front of) the fleet, so dependents can restore against an SDK-style, netnano1.0-targeted CoreLibrary.
How to solve the problem
Adopt the SDK-style CoreLibrary as the primary project and validate it as the leaf of the dependency graph:
- Make
CoreLibrary.Sdk.csproj (or the SDK-style equivalent) the primary project, building/packing against the published nanoFramework.NET.Sdk.
- Confirm it produces the corlib package correctly (mscorlib bootstrap; see the Corlib SDK variant in the SDK design) and that a downstream library restores and builds against it.
- Republish the package targeting
netnano1.0 so dependents no longer fall back to net to restore.
This is maintainer-owned (it lives in the CoreLibrary repo) and is the natural leaf-first first step of the fleet.
Acceptance: the SDK-style CoreLibrary is the primary project, builds/packs against the published SDK, publishes targeting netnano1.0, and a downstream library restores and builds against it.
Describe alternatives you've considered
- Keep the legacy CoreLibrary project as primary and migrate only leaf libraries. Rejected: everything depends on CoreLibrary, so the fleet cannot fully restore against SDK-style packages until CoreLibrary is republished against
netnano1.0.
Additional context
Description
CoreLibraryis the root of the dependency graph and a special case for the migration. An SDK-styleCoreLibrary.Sdk.csproj(targetingnetnano1.0) exists on themove-to-sdkbranch, and the published v2 previews already restore natively againstnetnano1.0, but the SDK-style project is not yet the primary project for the repository. Because every other library depends on CoreLibrary, it has to be migrated and republished cleanly before (or at the front of) the fleet, so dependents can restore against an SDK-style,netnano1.0-targeted CoreLibrary.How to solve the problem
Adopt the SDK-style CoreLibrary as the primary project and validate it as the leaf of the dependency graph:
CoreLibrary.Sdk.csproj(or the SDK-style equivalent) the primary project, building/packing against the publishednanoFramework.NET.Sdk.netnano1.0so dependents no longer fall back tonetto restore.This is maintainer-owned (it lives in the
CoreLibraryrepo) and is the natural leaf-first first step of the fleet.Acceptance: the SDK-style CoreLibrary is the primary project, builds/packs against the published SDK, publishes targeting
netnano1.0, and a downstream library restores and builds against it.Describe alternatives you've considered
netnano1.0.Additional context
CoreLibraryrepo; maintainer-owned. Leaf of the fleet; precedes the broaderlib-*migration.