CodeDress lets Visual Studio developers run strongly typed C# implementations of model classes and methods in MDriven Turnkey and MDrivenServer, while keeping the model as the application definition.

What CodeDress does

MDriven generates strongly typed C# representations of your model. Turnkey normally interprets the model declaratively at runtime. CodeDress connects these approaches: when Turnkey or MDrivenServer creates an object from the model, it can use the matching generated and compiled C# class from your uploaded model assemblies.

Use CodeDress when a requirement belongs in C# rather than OCL. For example, you can implement a model method in C# or provide C# logic for a derived attribute. Keep business logic in OCL where it describes the model well; OCL remains visible in the model, while C# implementation is maintained separately in source code.

CodeDress can be used in:

• Turnkey ViewModels and actions.
• Server-side ViewModels running on MDrivenServer.
• MDriven Designer prototype functionality, including WECPOF.

Requirements

• .NET Core or later.
• MDrivenServer.
• A model project that has been code-generated and built in Visual Studio.
• A <ModelName>_AssetsTK folder next to the model. This folder is the trigger that tells MDriven to collect assets for inclusion with the model upload.
• File-system permissions for the IIS application-pool identity when MDrivenServer or Turnkey runs under IIS.

How runtime dressing works

CodeDress follows this sequence:

1. You generate C# code from the model and build the project.
2. The compiled model assembly, and any required extra assemblies, are collected as model assets when the <ModelName>_AssetsTK folder exists.
3. You upload the model to MDrivenServer. The model assets are included in the uploaded Modlr zip.
4. MDrivenServer and Turnkey extract the code assets into a directory named ModelCodeAssemblies.
5. When Turnkey creates its type system, it scans ModelCodeAssemblies. If an assembly contains classes whose UmlElementAttributes identities match elements in the file-based model type system, Turnkey dresses those model types with the compiled classes.
6. New objects and objects read from persistent storage then use the dressed C# class where a matching class was found.

The model assembly must be on a path relative to the model at either bin/debug or ../bin/debug for asset collection.

Create and deploy CodeDress code

1. Generate and implement the model code

1. Open the model in Visual Studio. If the model opens as XML rather than as a model surface, see Documentation:Visual Studio.
2. Generate code with the C# button. If required, right-click the C# button and choose Generate all.
3. Implement the generated partial methods or class members in C#.
4. Build the solution.

For example, a model operation named CheckCodeDressingActive() can have a default OCL implementation that returns false. Its C# implementation can confirm that CodeDress is active:

public bool CheckCodeDressingActive()
{
  return true;
}

Without a matching dressed implementation, the OCL behavior remains in effect. With CodeDress active, the C# implementation returns true.

2. Ensure dependencies are copied

CodeDress uploads the assemblies needed to execute your model code. This includes extra assemblies referenced by your own implementation.

.NET 6 projects may not copy referenced assemblies to the model project's bin directory because the model project is not treated as an application. If required dependencies are absent from the model output directory, create an additional console application project that references the model project and configure its output to use the same output directory as the model project. Building that application causes the required dependency assemblies to be copied to the model output directory.

Before uploading, inspect the model output directory and verify that it contains the model assembly and the non-shared assemblies required by your code.

3. Upload the current model and assemblies

Always generate code and build before you upload the model. The upload sends the assemblies available at that time; uploading before a build can send assemblies that reflect an older version of the model.

1. Generate the model code.
2. Build the solution successfully.
3. Confirm that <ModelName>_AssetsTK exists next to the model.
4. Upload the model to MDrivenServer.
5. Start or restart the Turnkey application that uses the uploaded model.

For the relationship between the model, compiled code, and the MDrivenServer copy of the model, see Documentation:Code generation.

Configure IIS permissions

The IIS application-pool identity must be allowed to create and modify files and folders in the web-server file system where MDrivenServer runs. This is required because CodeDress assets must be extracted and mirrored into their runtime locations.

1. In Windows folder security for the relevant MDrivenServer directory, add the application-pool identity.
2. Use the identity format IIS APPPOOL\{app pool name}. For example, IIS APPPOOL\DefaultAppPool.
3. Select Check Names, then confirm the account.
4. Grant the account Modify permission.

When debugging a local Turnkey application, also ensure that its application-pool identity can access its log directory and ModelCodeAssemblies directory.

Check CodeDress status

Location	What to check
MDrivenServer	Open ModelVersionAdministration. After a successful upload, the expected status is CodeFoundAndDressed. It can take about a minute after upload before code is found and dressed.
Turnkey	In debug mode, open the Developer/ServerInfo page. It includes CodeDress status.

A status of CodeFoundButOutOfSync means code was found, but references in the code and DLL files have different versions. Follow Documentation:CodeFoundButOutOfSync to remove the conflicting DLL from the relevant ModelCodeAssemblies directories and upload again.

Assembly version rules

CodeDress loads assemblies at runtime. Shared MDriven Framework assemblies, including assemblies named eco.*.dll, must be compatible across the compiled model code, MDrivenServer, Turnkey, and MDriven Designer.

MDriven uses .NET assembly-resolution handling to prefer an already loaded assembly version over the version referenced by your code. This handling has two important limits:

• It cannot intercept an assembly load when the unwanted version is available in the Global Assembly Cache (GAC).
• It cannot intercept an assembly load when the unwanted version is located beside your code assembly in the same assembly search path.

Do not include shared eco.*.dll assemblies in the Modlr asset package. Version differences are especially likely to affect CodeDress prototyping in MDriven Designer. Keep the MDriven Framework version used to compile the model close to the Turnkey version that will load it.

Asset extraction and application restarts

MDriven writes a checksum file at App_Data/AssetsTKChecksum.xml when it extracts assets. It compares the complete Modlr zip checksum with this file on later starts.

When the checksum is unchanged, MDriven skips asset extraction and file mirroring. This reduces startup file operations and prevents IIS restart loops that can occur when many files change while MDrivenServer and a Turnkey application share the same host environment.

After you upload a changed model, it is expected that the application can return error pages one or two times while changed assets are unpacked and IIS restarts the host.

If Turnkey reports that no new assets are available but you need to force extraction, delete the Turnkey application's App_Data/AssetsTKChecksum.xml file and restart the application. For local IIS debugging, killing the relevant w3wp process and refreshing the Turnkey page forces the application to start and fetch assets again.

Source-control format

Manage the model and your C# source with standard source-control tools such as Git or Subversion.

Format	Use
.ecomdl	An XML-based model format made from multiple files. Its files are intended to be readable by source-control diff and merge tools.
.modlr	The ecomdl content in a zip archive. Use it when sending a model for review or distribution.

Troubleshooting

Symptom	Check and action
Code is not used after upload	Generate code, build, and upload again. Confirm that the <ModelName>_AssetsTK folder exists and that the compiled assemblies are in one of the supported relative output paths.
Required library cannot be loaded	Verify that the library was copied to the model output directory. For .NET 6 projects, use an additional console application project with the same output directory when needed to copy dependencies.
CodeFoundButOutOfSync	Remove the suspected conflicting DLL from ModelCodeAssemblies on both the Turnkey server and MDrivenServer, then upload again. See Documentation:CodeFoundButOutOfSync.
Assets do not refresh	Delete App_Data/AssetsTKChecksum.xml in the affected Turnkey application and restart it.
Extraction or mirroring fails	Check Modify permissions for the IIS application-pool identity on the MDrivenServer and Turnkey runtime directories.
You need breakpoints in model C# code	Use Documentation:Debug CodeDress for local IIS setup, process attachment, and an override that avoids repeatedly uploading assemblies to MDrivenServer.

See also

• Documentation:Code generation
• Documentation:Debug CodeDress
• Documentation:CodeFoundButOutOfSync
• Documentation:Visual Studio
• HowTos:Debug Turnkey Generic Code
• HowTos:Fix 'No suitable constructor found' Error