MeshWeaver.Blazor.EntityViews flips to the module lane - #2085
Merged
Conversation
The Analysis/#1974 shape, third PR of the extraction chain: the pack leaves the app closure and ships as a registry module. ## What makes the flip REAL: the closure edge through Graph had to go Dropping the portal's ProjectReference alone would have flipped nothing: MeshWeaver.Blazor.Graph (which STAYS app-closure) referenced EntityViews for FormComponentBase, so EntityViews.dll kept riding the closure transitively — and the module landing refuses a module whose entry DLL collides with an app-closure file, so the catalog package could never land (409 on every instance) while Modules:Required would hold every rollout on a module that could never install. So the shared form infrastructure returns to the base pack: FormComponentBase, InputBase, ListBase and OptionsExtension move back to src/MeshWeaver.Blazor/Components (app-closure infrastructure, shared with Graph's MeshNodePickerView), and Graph's EntityViews reference is deleted with a csproj note saying why it must never come back. OptionsExtension.MapToString goes public — its consumers (RadioGroupView & co.) are cross-assembly now. The module keeps the CONCRETE renderers: the ten form inputs and the three entity-editing skin views. Verified on the closure itself: Memex.Portal.Monolith's Release output carries MeshWeaver.Blazor.Graph.dll and NO MeshWeaver.Blazor. EntityViews.dll (Analysis absent too, as expected on the module lane). ## The two halves of an extraction - OUT of the image: Memex.Portal.Shared drops the reference and the compiled AddEntityViews() call; EntityViewsViewPackModuleAttribute (MeshNodeProviderAttribute) now folds the identical registration when the DLL is listed under Modules:Assemblies. - DECLARED required: MeshWeaver.Blazor.EntityViews.dll joins Modules:Required in BOTH portals (Distributed + Monolith), beside Radzen/Analysis/GoogleMaps/Speech — required_modules goes Unhealthy and readiness holds a rollout that lost the pack, instead of shipping blank edit forms behind a green rollout. Test projects that name the pack's types by NAME keep their direct ProjectReferences (Hosting.Blazor.Test: the registration gate, the style-contract harness) — a publish lane can never satisfy a by-name type reference (#2018), and the maintainer sanctioned test-side references explicitly. Content-surface check (the Maps/#2021 identity-fork trap): EntityViews drags no canonical content-surface assembly out of the closure — MeshWeaver.Application.Styles stays (Layout + Blazor still reference it, confirmed in the monolith output) and FrameworkBuildIdentityTest 23/23 green. ## Verified - Builds green (Release, warnings-as-errors): EntityViews, Blazor, Blazor.Graph, Memex.Portal.Shared(+Test), Memex.Portal.Monolith, Memex.LocalMesh. - Suites: Hosting.Blazor.Test 444/444 (incl. the 13-row EntityViews gate — the pack still registers everything it claims), Layout.Test 474/474, Graph.Test green, FrameworkBuildIdentity 23/23. The catalog package (MeshWeaver.Plugins EntityViews/, built from THIS repo's src/ by the module-pack matrix) follows ONLY after this merges — publishing it while the image still ships the DLL in the app closure would 409 on every instance. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Contributor
There was a problem hiding this comment.
Pull request overview
This PR completes the “module lane” flip for MeshWeaver.Blazor.EntityViews by removing the remaining app-closure edge (via MeshWeaver.Blazor.Graph) and switching the portal composition from a compiled AddEntityViews() call to module-driven registration, while also declaring MeshWeaver.Blazor.EntityViews.dll as a required module in both portal hosts.
Changes:
- Move shared form infrastructure back into the base pack (
MeshWeaver.Blazor.Components) and makeOptionsExtension.MapToStringpublic for cross-assembly use. - Remove the
MeshWeaver.Blazor.Graph→MeshWeaver.Blazor.EntityViewsproject reference and update Graph imports/usings accordingly. - Make EntityViews self-register as a module via a
MeshNodeProviderAttribute, drop the portal’s direct reference/registration call, and add EntityViews toModules:Requiredin both portal appsettings.
Reviewed changes
Copilot reviewed 16 out of 16 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
| src/MeshWeaver.Blazor/Components/OptionsExtension.cs | Moves to MeshWeaver.Blazor.Components and exposes MapToString publicly for consumers in the EntityViews pack. |
| src/MeshWeaver.Blazor/Components/ListBase.cs | Updates namespace/aliases to the base-pack location of OptionsExtension.Option. |
| src/MeshWeaver.Blazor/Components/InputBase.cs | Moves shared input base into MeshWeaver.Blazor.Components. |
| src/MeshWeaver.Blazor/Components/FormComponentBase.cs | Moves shared form base into MeshWeaver.Blazor.Components. |
| src/MeshWeaver.Blazor.Graph/MeshWeaver.Blazor.Graph.csproj | Removes the EntityViews project reference and documents why it must not be reintroduced. |
| src/MeshWeaver.Blazor.Graph/MeshNodePickerView.razor.cs | Switches the base-class import to MeshWeaver.Blazor.Components. |
| src/MeshWeaver.Blazor.Graph/BlazorGraphExtensions.cs | Updates commentary to reflect the new “base pack shared infra” shape. |
| src/MeshWeaver.Blazor.Graph/_Imports.razor | Drops @using MeshWeaver.Blazor.EntityViews from Graph pack imports. |
| src/MeshWeaver.Blazor.EntityViews/README.md | Updates documentation to reflect module-lane activation and the base-pack location of shared bases. |
| src/MeshWeaver.Blazor.EntityViews/MeshWeaver.Blazor.EntityViews.csproj | Adds a package description reflecting module shipping/activation. |
| src/MeshWeaver.Blazor.EntityViews/EntityViewsViewPackModuleAttribute.cs | Introduces module-driven registration via an assembly-level MeshNodeProviderAttribute. |
| src/MeshWeaver.Blazor.EntityViews/_Imports.razor | Updates the Option alias to point at the base-pack type. |
| memex/Memex.Portal.Shared/MemexConfiguration.cs | Removes the compiled .AddEntityViews() registration call and documents module-based registration. |
| memex/Memex.Portal.Shared/Memex.Portal.Shared.csproj | Drops the ProjectReference to EntityViews to keep it out of the app closure. |
| memex/Memex.Portal.Monolith/appsettings.json | Declares MeshWeaver.Blazor.EntityViews.dll as required (readiness-gated). |
| memex/aspire/Memex.Portal.Distributed/appsettings.json | Declares MeshWeaver.Blazor.EntityViews.dll as required (readiness-gated). |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
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
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.
What
PR 3 of the extraction chain (#2080 → #2081 → #2082 → this):
MeshWeaver.Blazor.EntityViewsleaves the app closure and ships as a registry module — the Analysis/#1974 shape, with both halves of an extraction: OUT of the image, and DECLARED required.What makes the flip REAL: the closure edge through Graph had to go
Dropping the portal's ProjectReference alone would have flipped nothing:
MeshWeaver.Blazor.Graph(which stays app-closure) referenced EntityViews forFormComponentBase, soEntityViews.dllkept riding the closure transitively — and the module landing refuses a module whose entry DLL collides with an app-closure file, so the catalog package could never land (409 on every instance) whileModules:Requiredwould hold every rollout on a module that could never install.So the shared form infrastructure returns to the base pack:
FormComponentBase,InputBase,ListBaseandOptionsExtensionmove back tosrc/MeshWeaver.Blazor/Components(app-closure infrastructure, shared with Graph'sMeshNodePickerView), and Graph's EntityViews reference is deleted with a csproj note saying why it must never come back.OptionsExtension.MapToStringgoes public — its consumers (RadioGroupView& co.) are cross-assembly now. The module keeps the CONCRETE renderers: the ten form inputs and the three entity-editing skin views.Verified on the closure itself:
Memex.Portal.Monolith's Release output carriesMeshWeaver.Blazor.Graph.dlland noMeshWeaver.Blazor.EntityViews.dll(Analysis absent too, as expected on the module lane).The two halves
Memex.Portal.Shareddrops the reference and the compiledAddEntityViews()call; a newEntityViewsViewPackModuleAttribute(MeshNodeProviderAttribute) folds the identical registration when the DLL is listed underModules:Assemblies.MeshWeaver.Blazor.EntityViews.dlljoinsModules:Requiredin BOTH portals (Distributed + Monolith), beside Radzen/Analysis/GoogleMaps/Speech —required_modulesgoes Unhealthy and readiness holds a rollout that lost the pack, instead of completing into a portal whose edit forms went blank.Test projects that name the pack's types by NAME keep their direct ProjectReferences (
ViewPackRegistrationGateTest,ControlStyleRenderingTest) — a publish lane can never satisfy a by-name type reference (#2018).Content-surface check (the Maps/#1814/#2021 identity-fork trap)
EntityViews drags no canonical content-surface assembly out of the closure:
MeshWeaver.Application.Stylesstays (Layout + Blazor still reference it — confirmed present in the monolith output) andFrameworkBuildIdentityTestis 23/23 green, includingCanonicalContentSurface_IsRecordedByEverySurfaceManifestHost.Verification
Ordering (stated here and in the package PR)
🚨 The catalog package (MeshWeaver.Plugins
EntityViews/, whose module-bundle matrix entry builds THIS repo'ssrc/MeshWeaver.Blazor.EntityViewsfrom the platform checkout) lands only after this merges: publishing the bundle while the image still ships the DLL in the app closure would 409 the module landing on every instance.Operational note for the next deploy: a portal rolling to a post-this-PR image will hold readiness (
required_modules) until the EntityViews package is installed from the registry — that is the gate doing its job; install the package to complete the rollout.🤖 Generated with Claude Code