You can use this page to identify behavior changes that can require model, action, code, package, or server updates when you upgrade MDriven.
Before you upgrade
Review the entries that apply to the MDriven version you are moving from and test the upgrade outside production first.
- Update the MDriven components that must work together. In particular, apply the stated MDrivenServer update when a checksum change requires it.
- Open and validate your model in MDriven Designer. Resolve model errors before publishing or generating code.
- Test ViewModel actions that open modal views, especially their AfterModalOk actions.
- Check database changes before evolving a database. A renamed association or attribute can otherwise cause an existing database column to be replaced.
- If your application contains custom .NET code or plugins, review Documentation:MDriven 7.2 before moving to MDriven 7.2.
2025 March
14 March: vModalResult_selfVM removed from AfterModalOk
The variable vModalResult_selfVM is no longer available in an AfterModalOk action.
This change corrects an earlier WPF issue: dirty objects (vDirties) were not handed back correctly to the view that opened the modal view. As a workaround, some actions used vModalResult_selfVM.save. Dirty-object handover now behaves the same in Turnkey and WPF, so that workaround has no effect and the variable was removed to make the change explicit.
What you need to do
- Find AfterModalOk actions that reference
vModalResult_selfVM. - Remove the reference, including calls such as
vModalResult_selfVM.save. - Retest the modal workflow in the client types you support. Confirm that changes made in the modal view appear in the view that opened it.
| Earlier workaround | Current behavior |
|---|---|
vModalResult_selfVM.save in AfterModalOk
|
Remove it. The framework hands dirty objects back to the instigating view. |
2025 February
26 February: model checksum calculation changed
The model checksum now includes the names of an association's two association ends. Earlier checksum calculation did not include those names, which meant code generation could fail to discover an association-end name change.
Checksum compilation also now sorts states by state name. Trigger ordering was corrected on 6 February 2025. These ordering changes prevent client and server checksums from differing only because states or triggers were stored in a different order.
Required update
Update both the client-side MDriven components and MDrivenServer. An older MDrivenServer cannot recognize the new checksum format. Use matching components released from 4 February 2025 or later; include the trigger-ordering correction released on 6 February 2025 or later.
Example
If you rename an association end, regenerate and deploy with an updated MDrivenServer. With the corrected checksum, the change is detected rather than being missed by code generation.
Preserve data when renaming modeled storage
A model rename can be a database-breaking change. For example, if an association end stores a foreign key and you rename that end, database evolution can drop the old foreign-key column and create a new one. Existing relationships can then be lost.
When you rename an attribute, association, or association end whose prior name exists in the database, enter its previous name in the artifact's Former names property before checking the database changes. This lets the rename logic move the existing column rather than treat it as a dropped column and a new column.
- Select the renamed modeled artifact in MDriven Designer.
- Set Former names to the name used before the rename.
- Check the proposed database changes.
- Verify that the change preserves or moves the existing storage rather than dropping it.
- Apply the change only after you have reviewed it and backed up data as required by your deployment process.
For the limits of automatic evolution, see Documentation:Database evolve.
2025 January
Two optional package checks are now enabled by default. These checks reject ViewModel expressions that were previously accepted but are not logically valid.
Stricter Requires-Root rules
At the root level of a ViewModel, you may use self only when the ViewModel's Requires-Root setting is selected.
Example: If a root-level expression is self.Name, enable Requires-Root on that ViewModel. If the ViewModel does not require a root object, rewrite the expression so it does not depend on root-level self.
Stricter vCurrent_ recursion rules
A vCurrent_ variable may not be used in nesting levels below the nesting where that vCurrent_ was defined. Such a reference cannot identify the intended current object at the deeper level.
Example: If an expression in a deeper nesting refers back to an outer vCurrent_..., replace the invalid reference with an expression based on self when the expression is intended to address the object at that deeper nesting.
2021 February
self is not valid in ViewModel context actions
In a ViewModel context action, self is undefined. Class actions have self; ViewModel actions use a current-object variable instead. Earlier versions could sometimes appear to accept self in a ViewModel context action, but the result could be model errors or a view that did not display.
Replace self with vCurrent_<TheViewOwningTheAction>.
| Action context | Object reference | Example |
|---|---|---|
| Class action | self
|
self.Name
|
| ViewModel context action | vCurrent_<TheViewOwningTheAction>
|
vCurrent_Order.Name
|
For simple expressions, use the MDriven Designer debugger to test the replacement expression. After changing actions, validate the model and open the affected views to catch errors that were previously hidden.
Framework compatibility changes
All oclColumns must contain legal OCL
An oclColumn is a column whose value is defined by an OCL expression. The framework now validates every oclColumn during derivation, including columns that are not currently used by a view. An invalid expression causes an exception by default.
Fix the OCL expression rather than relying on an unused column being ignored. If you need failed derivations to be written to trace output instead of throwing an exception, set:
AbstractDeriver.ThrowExceptionOnFailedDerivation=false;
The default value is true.
VariableHandle default nesting and property loading changed
The default values of AddDefaultNestings and AddDefaultProperties on a VariableHandle changed from true to false. The former defaults added an unnecessary load.
If your expression needs self, set AddSelfColumn on the VariableHandle rather than restoring default nestings and properties.
| Requirement | Recommended setting |
|---|---|
An expression needs self
|
Set AddSelfColumn on the VariableHandle.
|
| Existing code assumes default nestings or properties are present | Review the handle and explicitly add the data it requires. |
MDriven 7.2 upgrade
MDriven 7.2 includes .NET and assembly-package compatibility changes that can affect generated WinForms code, custom components, plugins, and asynchronous handling. It also removes WCF as a supported PMapper communication channel and does not support EnterpriseServices distributed transactions in .NET 6 or later.
Follow the complete migration instructions in Documentation:MDriven 7.2. That page specifies the replacement MDriven.*.netStandard packages, the WinForms generated-code adjustment from Eco.Handles.IColumn[] to Eco.Handles.AbstractColumn[], and the required platform-dispatcher injection for asynchronous handling.