Summary
The generator silently overwrites cmdlet files when two operations resolve to the same cmdlet name, which drops cmdlets without any error, the same failure mode AutoRest had.
What's working now
One .g.cs file is written per cmdlet and for almost every path this is correct. Modules build and import cleanly, and the parity gate verifies the names of the files that survive.
How can we make it better
When two operations produce the same cmdlet name, the second file overwrites the first with no warning. Verified in the Sites module: GetMgSite.g.cs contains the sub-sites call (client.Sites[SiteId].Sites[SiteId1]), because it overwrote the plain get-site-by-id cmdlet. No test or gate can catch this today since the surviving file compiles and imports.
The fix is two steps: track written file names and fail generation on any collision, then resolve the known collisions with rename entries (the published SDK ships Get-MgSubSite for this exact case).
Summary
The generator silently overwrites cmdlet files when two operations resolve to the same cmdlet name, which drops cmdlets without any error, the same failure mode AutoRest had.
What's working now
One
.g.csfile is written per cmdlet and for almost every path this is correct. Modules build and import cleanly, and the parity gate verifies the names of the files that survive.How can we make it better
When two operations produce the same cmdlet name, the second file overwrites the first with no warning. Verified in the Sites module:
GetMgSite.g.cscontains the sub-sites call (client.Sites[SiteId].Sites[SiteId1]), because it overwrote the plain get-site-by-id cmdlet. No test or gate can catch this today since the surviving file compiles and imports.The fix is two steps: track written file names and fail generation on any collision, then resolve the known collisions with rename entries (the published SDK ships
Get-MgSubSitefor this exact case).