kopecp/web-view2-demo_multiwersion

1. Overall shape

This repo is a two-process demo architecture: a Revit add-in written in .NET and a separate web application in Vue 2. The add-in hosts the Revit-side runtime; the web app is the UI surface. They communicate through a local bridge, and the actual Revit actions are pushed into versioned, load-on-demand DLL packages.

2. Revit add-in boundary

RevitWebView2Demo is the main executable add-in. It contains the Revit entry points, dockable window/WebView hosting, event handlers, and the runtime that loads and executes packages. This is the boundary that talks directly to Revit API and must respect Revit’s external event model.

3. Shared contracts

RevitWebView2Demo.Abstractions defines the contract layer between the host and the packages. IRevitPackageCommand and RevitPackageContext establish the minimum interface and execution context needed so that package DLLs can be loaded independently without tight coupling to the host implementation.

4. Versioned package subsystem

RevitWebView2Demo.Packages.CreateSheet and RevitWebView2Demo.Packages.SelectElements are sample Revit API packages. Each package has its own project and manifest, and is meant to be deployed as a separately versioned artifact rather than compiled into the host add-in. This is the key “plugin-of-plugins” boundary in the architecture.

5. Package runtime inside the add-in

The PackageRuntime folder implements the dynamic loading pipeline:

- manifest parsing and package metadata,

- path validation,

- assembly resolution,

- loading package assemblies,

- queueing/executing package requests,

- returning execution results.

This runtime is the mechanism that turns a web request into a live Revit API operation.

6. Safety and isolation around package loading

PackagePathGuard, PackageAssemblyResolver, PackageSourceMarker, and related types show that package loading is intentionally constrained. The host validates where packages come from and controls resolution so the add-in does not blindly load arbitrary DLLs. This is an important architectural boundary because packages are externalized and versioned.

7. Revit UI interaction model

Revit actions are mediated by event handlers such as RevitWv2EventHandler, SelectExternalEventHandler, and UI commands like ShowWebViewDockCommand / ShowWebView2Window. This reflects the Revit pattern where external events are used to marshal work back onto the Revit UI thread rather than calling API operations directly from the web bridge.

8. Web-to-Revit communication layer

BrowserBridge contains the local messaging infrastructure: a server, message envelopes, and outbound message types. Its role is to carry commands and responses between the browser UI and the add-in. The README indicates a local WebSocket bridge is used, with a fallback path through registry relay.

9. Registry relay as an alternate connection path

RegistryRelay is a secondary communication subsystem consisting of client, web connection, message types, and a command to inspect active connections. Architecturally, this is a discovery/relay mechanism that helps the browser and the add-in find each other locally without hard-wiring a single communication path.

10. Web application

The web folder is a standalone Vue 2 application with routing, a Revit demo component, and a small utility layer for webview/connection integration. It is the user-facing control plane for triggering Revit operations, not the place where Revit API logic lives.

11. Web server and published package registry

web/server.js and web/revit-registry.js provide the local HTTP/WebSocket-serving side for development and connection coordination. The public/revit-packages/... tree acts as a package registry: the packaged DLLs and their package.json manifests are published here so the add-in can fetch them at runtime.

12. Build and packaging pipeline

tools/PackRevitPackage.ps1 is the packaging step that turns a package DLL into the web-published artifact format. The repo’s architecture depends on this split: packages are built from the Revit-package projects, packed, then served from the web app’s public directory for runtime download.

13. Deployment assumptions

The solution is explicitly tied to Windows, Autodesk Revit versions 2022/2024/2025, and local install paths for RevitAPI.dll/RevitAPIUI.dll. The add-in build copies artifacts into the user’s Revit add-ins folder, while the web app assumes a local dev server at http://localhost:8080/ during development.

14. End-to-end data flow

A typical request path is:

web UI action → browser bridge / relay message → add-in receives request → package runtime resolves and loads the target versioned DLL → external event executes Revit API work → result returns back through the bridge to the web UI.

This is the central architecture diagram to capture: UI, bridge, host runtime, and package execution are separate layers with explicit message passing between them.