Documentation:Code generation

Code generation

This page was created by Lars.olofsson on 2017-12-20. Last edited by Wikiadmin on 2026-07-29.

Code generation (also called Codegen) lets you generate C# code from an MDriven model for use in a Visual Studio project; use it when your application includes generated model classes, model methods implemented in C#, or CodeDress.

What code generation does

MDriven generates C# files from the classes and operations in your model. The generated code gives your compiled application a representation of the model.

For example, if you add a class named Order to the model and generate code, the Visual Studio project receives generated C# for Order. If you later add an attribute or remove a model method, generate and build again before you run or deploy the application.

Generated code also contains identifiers and checksum information that let MDriven compare the model represented by compiled code with the model used at runtime. This comparison prevents an old client model from saving data against a changed server model.

Keep the model representations synchronized

For an application that uses generated code, the model can exist in several places. Keep these representations aligned.

Representation	Used by	How you update it
Your model in MDriven Designer	The model you work with and the model used when you run from the designer.	Save your model changes.
Generated and compiled C# code	Your local application at runtime. When the EcoSpace starts, its compiled model representation is reflected back into the runtime model.	Generate C# code, then build the Visual Studio project.
Model uploaded to MDrivenServer	Server-side calls and the Web UI hosted by the server.	Upload the model after generation and a successful build.
Compiled model assemblies when using CodeDress	C# implementations of model methods that MDrivenServer must use.	Build first, then upload the model so the current assemblies are sent with it.

If the representations differ, checksums can differ. MDrivenServer can then refuse to save data rather than allow a client with an outdated model to write incorrect data. For example, a client built before an attribute was reordered or changed must not continue saving as though its old attribute layout were current.

Generate, build, and upload

Use this sequence after changing the model.

Save the model and confirm that it contains the intended changes.
In MDriven Designer or the Visual Studio integration, select the C# generation button to refresh generated code.
If you need to regenerate all generated code, right-click the C# button and choose the command to generate all code. Use this when a normal generation does not update the files you expect.
Build the Visual Studio project. Resolve compilation errors before uploading.
Upload the model to MDrivenServer.
Start or restart the local application or Turnkey server that will use the updated model.

When you use CodeDress, step 4 is required before step 5. Uploading after an unsuccessful or skipped build can send assemblies that represent an older version of the model.

Work with multiple packages

A package is a model-level grouping of classes and other model elements. When one package needs code access to types in another package, declare that dependency on the package.

Select the package that needs access to another package.
In the Property Inspector, add the name of the other package to the package's referenced package names.
Generate code and build the project.

For example, if package Sales has a method that uses the Customer class in package CRM, add CRM to the package references for Sales before generating code. This ensures the generated code respects the package boundary while allowing the required type access.

Generated methods and model changes

Generated model methods are tied to model elements through their UML element identifiers. Do not leave C# implementations for methods that have been removed from the model or changed to have an OCL or EAL expression in the method body.

If generated code contains ObsoleteYOUNEEDTOACT, code generation found a C# method whose UML element identifier no longer corresponds to a method implemented as C# in that class. Remove or reconcile that obsolete implementation, then generate and build again. The deliberately non-compiling attribute requires action because stale methods can cause a mismatch between checksums obtained from compiled code and from the model. Such a mismatch can prevent MDrivenServer from allowing database saves.

For generated constructors and the alternative approach when you implement behavior in EAL rather than C#, see Documentation:Constructor in generated code.

Troubleshoot generation problems

Start with the symptom that matches your situation.

Symptom	What to do
Code generation reports that files may be locked by Visual Studio.	Close every Visual Studio tab that displays generated code. If the problem remains, close and restart Visual Studio, then generate again. See Documentation:Codegen failed.
One or more classes are not generated or do not appear correctly in Visual Studio.	Check the generated file entries and their `DependentUpon` relationship in the project file. If source-control merging damaged this structure, exclude—not delete—the affected generated `.cs` and `.eco.cs` files, then regenerate all code. Follow HowTos:Fix Code Generation Issues.
Code generation is unreliable in an SDK-style or .NET Standard project.	Review the project-file settings and generated-file dependency configuration in Documentation:Codegen Issues .net standard.
The model opens as XML instead of a model surface in Visual Studio.	Verify the MDriven Framework installation for your Visual Studio version and correct the `ecomdl` item configuration in the project file. See Documentation:Visual Studio.
Generation fails unexpectedly and the project has a Solution Items node.	Remove the Solution Items node, then try generation again. See Documentation:Codegen failed.

Contents