You can use this historical guidance to prevent Mono/WebAssembly linker stripping from removing MDriven-generated constructors when running a 2020 WebAssembly build.
Scope and status
This page records WebAssembly (WASM) linker workarounds from 2020. Apply them when a WASM build throws a missing-method exception because code needed by MDriven at runtime was removed during linking.
WASM is the browser-execution format used by client-side .NET applications. The Mono linker removes code that it cannot determine is used. MDriven can use reflection at runtime to determine what to instantiate, so a constructor can be required even when the linker cannot find a direct call to it.
The result can be a runtime exception reporting missing method information.
Why the linker removes required code
The linker analyzes statically visible usage and prunes unused members to reduce the client download. Reflection changes this situation: a type or constructor may be selected at runtime rather than referenced directly in application code.
For example, a generated class constructor may be needed when MDriven creates an object from model metadata. If no compiled code directly calls that constructor, the linker can remove it even though the application needs it later.
Preserve generated model constructors
For generated model code, add the CodeGen.GenerateConstructorReferences tagged value to the relevant package. MDriven then generates references to important constructors so that the linker can see they are used.
- In MDriven Designer, select the package containing the generated types that must remain available at runtime.
- Add the tagged value
CodeGen.GenerateConstructorReferencesto that package. - Regenerate the code.
- Add a direct call to the generated reference method from code that is included in the WASM application:
YourPackage.ConstructorReferatorToAvoidLinkerStripping();
- Rebuild the WASM application and repeat the scenario that previously produced the missing-method exception.
Replace YourPackage with the generated package name in your application. The direct call is required: it ties your application code to the generated reference method and prevents the linker from removing the constructors that method references.
Preserve generated ViewModel constructors
The same linker behavior can affect code-generated ViewModels. Add a call to the generated ViewModel reference method in code that is retained by the WASM application.
ClassLibrary1.ViewModelCodeGen_ViewModel1.ViewModel1.ReferenceToAllConstructorsToHelpWasmLinker();
Use the generated namespace, code-generation class, and ViewModel name from your own project. This call makes all constructors for that generated ViewModel visible to the linker.
| Situation | Required action |
|---|---|
| A generated model constructor is missing at runtime | Add CodeGen.GenerateConstructorReferences to the relevant package, regenerate, and call ConstructorReferatorToAvoidLinkerStripping().
|
| A code-generated ViewModel constructor is missing at runtime | Call that ViewModel's ReferenceToAllConstructorsToHelpWasmLinker() method from retained application code.
|
Preserve attribute
MDriven code generation also generates a Preserve attribute. The Mono linker recognizes this attribute and does not prune the marked code even when it finds no visible usage.
Treat the generated constructor-reference calls as part of the linker-preservation setup. Do not remove them merely because they appear not to perform application work; their purpose is to establish a static usage path for the linker.
Diagnose a missing-method failure
- Reproduce the failure in the browser and record the missing type or method from the exception.
- Determine whether it belongs to generated model code or generated ViewModel code.
- For model code, verify that the package has
CodeGen.GenerateConstructorReferences, regenerate, and verify that the generatedConstructorReferatorToAvoidLinkerStripping()call is present in retained application code. - For ViewModel code, add or verify the corresponding
ReferenceToAllConstructorsToHelpWasmLinker()call. - Rebuild the WASM output and retest the same runtime path.
Related browser-client work
For general MDriven and Blazor compatibility notes, see Documentation:Blazor. If you are packaging custom Razor components for a Turnkey application, including the browser-side WASM files and their compressed variants, follow Documentation:EXT ComponentsBlazor rather than using the constructor-preservation steps on this page.