Skip to content

fix(wrapper-generator): make wrapper packages installable from a feed - #3740

Open
Joywambui-maina wants to merge 2 commits into
feat/wrapper-runtime-basefrom
feat/wrapper-packaging
Open

fix(wrapper-generator): make wrapper packages installable from a feed#3740
Joywambui-maina wants to merge 2 commits into
feat/wrapper-runtime-basefrom
feat/wrapper-packaging

Conversation

@Joywambui-maina

Copy link
Copy Markdown

Changes proposed:

Declare Microsoft.Graph.Authentication as a NuGet dependency in every wrapper nuspec (open floor matching the manifest minimum) — Install-Module resolves from package metadata, not the manifest, so without this a clean machine got a wrapper that could not import
Version every package as a prerelease (-Prerelease, default wrapperpreview01) so previews can never collide with the service-module release train's stable versions
Derive a stable RFC 4122 name-based module GUID from the module name — identical across builds with no lookup table, extending the shipped SDK's locked-GUID convention to never-published modules
Correct two comments (Std.UriTemplate's actual requester; the live gate's committed name)
Validation:
38/38 packages verified three rounds each (dependency, label, distinct stable GUIDs, with negative controls); clean-machine proof three rounds — Save-Module from a folder repository auto-resolves Authentication and the saved layout imports and completes a live Graph call in a host that can see nothing else; package gate PASS ×3; GUID algorithm verified against the RFC 4122 canonical test vector.

The #3712 evidence sweep found four defects between "packages exist" and
"testers can install them": the nuspec declared no dependencies, so a clean
machine got the wrapper without Authentication and import failed
(Install-Module resolves from NuGet metadata, not the manifest); packages
versioned as stable 2.39.0, colliding number-for-number with the real SDK's
release train; the module GUID was random every build, breaking Update-Module
identity across handout iterations; and both checkouts held stale pre-fix
nupkgs under shipping ids. Packages now declare Microsoft.Graph.Authentication
as an open-floor dependency (matching the manifest minimum and the use-latest
ruling), always carry a prerelease label (-Prerelease, default
wrapperpreview01), and derive a stable RFC 4122 name-based GUID from the
module name - no lookup table, identical across builds. Stale artifacts
deleted. Proven three rounds each: 38 of 38 packages carry the dependency,
label and distinct stable GUIDs; Save-Module from a folder repository
auto-resolves Authentication, and the saved layout imports and completes a
live Graph call in a host that can see nothing else; package gate PASS. Also
corrects the Std.UriTemplate comment - the AssemblyRef lives in
Microsoft.Kiota.Abstractions, not the HTTP library - and the live gate's
committed name (tools/Test-WrapperLive.ps1).

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Updates the wrapper-module generator so wrapper packages can be installed from a NuGet feed with correct dependency resolution, stable identities, and non-colliding preview versioning.

Changes:

  • Adds a mandatory prerelease label for wrapper packages and applies it consistently to manifests and nuspec versions.
  • Derives a deterministic RFC 4122 v5 GUID from the module name to keep wrapper module identity stable across builds.
  • Declares Microsoft.Graph.Authentication as an explicit nuspec dependency (in addition to manifest RequiredModules) so Install-Module can resolve it from package metadata.

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

Comment thread tools/Build-WrapperModule.ps1 Outdated
Comment on lines +90 to +91
# replace. The label is alphanumeric only - the PowerShellGet prerelease grammar allows
# nothing else.
…ue per build

Wrapper packages took their version from config/ModuleMetadata.json, which
tracks the v2 service-module release train - so a preview claimed 2.39.0, a
version the real SDK is about to publish - and every build reused one static
prerelease label, leaving two packages able to share an id and version while
differing in content. Packages are now 3.0.0 by default, the v3 line the
wrapper modules actually are, with a prerelease label that is distinct per
build: alpha<BuildId> in CI, alpha<UTC timestamp> locally. The label stays
alphanumeric because the documented PowerShellGet grammar allows a hyphen
only as the first character and no period at all, so the alpha-4472 shape is
invalid however leniently local tooling treats it; alpha4472 matches both the
documentation's examples and the repo's own ci<BuildId> convention.
ModuleMetadata.json is still the single source for authors, tags and licence.
Proven three rounds: a clean machine installs the prerelease package from a
folder repository, resolves Authentication from nuspec metadata, imports and
completes a live Graph call seeing nothing else; package gate PASS.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants