You can debug C# CodeDress code in a local MDriven Turnkey application when you need breakpoints, fast code iterations, or a focused test harness against data on an MDrivenServer.

CodeDress is the mechanism that lets the runtime use C# classes generated from, and implemented for, your model. Choose the scenario that matches where you want Turnkey to obtain the CodeDress assemblies and where you want to run the code.

Before you start

You need:

• A local MDriven Turnkey application running under IIS, with access to the files that it must create and update.
• Visual Studio and the solution that contains the model and its CodeDress implementation.
• A model built for the same runtime family as the server. A .NET Core server cannot load CodeDress built from a .NET Framework model project. Create and build a .NET Core model project when the server is .NET Core.
• The same, or compatible, MDriven Framework and Turnkey versions in Visual Studio and in the local Turnkey installation. A version mismatch can load incompatible interfaces or assemblies.
• Access to the target MDrivenServer when you use server-backed scenarios.

For CodeDress packaging, assembly locations, runtime behavior, and deployment requirements, see Documentation:CodeDress. For the general procedure for opening and debugging local Turnkey generic code, see HowTos:Debug Turnkey Generic Code.

Prepare the model assemblies

Before debugging code from your model:

1. Generate code from the model. See Documentation:Code generation.
2. Build the solution.
3. If you are using the server-backed workflow, upload the built model after the build completes. Building first makes the current CodeDress assemblies available for upload.
4. Confirm that CodeDress assets are configured as described in Documentation:CodeDress. In particular, asset collection requires a <ModelName>_AssetsTK folder next to the model, and the assemblies must be available at bin/debug or ../bin/debug, relative to the model.

If your code uses additional assemblies that do not appear in the model output, make the model output complete before upload. Documentation:CodeDress describes using a console application that references the model and writes to the model output location.

Give IIS access to runtime folders

Turnkey expands model assets and uses runtime files when it starts. The IIS application-pool identity must be able to modify the relevant folders, including the Turnkey log folder and ModelCodeAssemblies.

1. In Windows folder security, add the application-pool identity in the form IIS APPPOOL\{app pool name}. For example, IIS APPPOOL\DefaultAppPool.
2. Select Check Names, then confirm the identity.
3. Grant Modify permission to the folders that Turnkey must write to.

Do not diagnose a missing assembly or a breakpoint problem before checking these permissions. A process that cannot update ModelCodeAssemblies cannot load the expected CodeDress output.

Choose a debugging scenario

Scenario	Use it when	Where CodeDress assemblies come from
1. Turnkey with server-downloaded assemblies	You want to debug the exact model version uploaded to an MDrivenServer.	The MDrivenServer model package, downloaded when local Turnkey starts.
2. Turnkey with a local assembly override	You want server data but do not want to upload every code edit before debugging.	A local build directory specified by CodeDressOverride.
3. Local prototype and test harness	You want the shortest edit-debug loop, targeted calls, or automated tests while retaining access to server data.	Assemblies near the local model; the local prototype configuration selects the model.

Scenario 1: Debug Turnkey CodeDress with data from an MDrivenServer

Use this scenario to run local Turnkey against an MDrivenServer and debug the assemblies that Turnkey downloads with the model package.

Configure the server connection

1. In the local Turnkey installation, create the active MDrivenServerOverride.xml from the supplied template files, following the local Turnkey setup convention.
2. Set the MDrivenServer URL and the password for the MDrivenServer user in the override file:

<MDrivenServerOverride MDrivenServerPWD="pwd for mdrivenserver user a">https://&lt;urltomdrivenserver usually ending with __MDrivenServer&gt;</MDrivenServerOverride>

1. Start the local Turnkey application and verify in its log that it connects to the configured MDrivenServer and obtains the model.

At startup, Turnkey receives the model package and expands CodeDress assets to ModelCodeAssemblies. When the type system is created, Turnkey scans this directory and dresses matching model types with the corresponding C# classes.

Refresh downloaded assets when needed

Turnkey checks App_Data/AssetsTKChecksum.xml against the model package checksum. When the checksum is unchanged, it skips asset extraction and mirroring. This behavior reduces startup file work, but it can mean that a restart does not re-extract assemblies.

To force Turnkey to extract assets again:

1. Stop the worker process for the local application pool by ending the corresponding w3wp process.
2. Delete App_Data/AssetsTKChecksum.xml in the local Turnkey application.
3. Refresh the local Turnkey site so IIS starts the application again.
4. Review the log for asset extraction and CodeDress activity.

An application can return error pages one or two times immediately after a new model upload because unpacking changed assets can restart the host.

Attach Visual Studio

1. In Visual Studio, open the solution containing the model and CodeDress code.
2. Generate code, build the solution, and upload the current model to the target MDrivenServer.
3. Restart local Turnkey as described above so it downloads the current package.
4. Select Debug > Attach to Process.
5. Enable Show processes from all users. Administrator privileges are required for this view and attachment.
6. Select the w3wp process that belongs to the local Turnkey application pool.
7. Attach using managed code appropriate to the installed runtime. For a .NET Framework Turnkey application, select managed .NET Framework 4 code.
8. Invoke the ViewModel action or other UI behavior that calls your model code. Visual Studio stops at a breakpoint in the matching CodeDress source.

Example: set a breakpoint in a C# implementation of a model operation, open a Turnkey view that invokes its action, and perform that action. If the runtime has loaded the matching assembly, the breakpoint is hit.

Scenario 2: Debug Turnkey CodeDress without uploading each code change

Use this scenario when Turnkey should continue to use data and the model from an MDrivenServer, but should load CodeDress assemblies directly from your local build output.

1. Build the model solution so the local CodeDress assembly directory contains the current code.
2. Update MDrivenServerOverride.xml with the MDrivenServer URL, password, and CodeDressOverride path:

<MDrivenServerOverride MDrivenServerPWD="pwd for mdrivenserver user a" CodeDressOverride="C:\PathToCodeDress_bin_Debug_assemblies">https://&lt;urltomdrivenserver usually ending with __MDrivenServer&gt;</MDrivenServerOverride>

1. Grant the local Turnkey application-pool identity Modify access to the override directory.
2. End the local Turnkey w3wp process and refresh the site.
3. Attach Visual Studio to the correct w3wp process.
4. Make a code change, build it, restart w3wp, refresh the site, and invoke the code path again.

The model on the MDrivenServer must still match the model used by your local Visual Studio solution. This scenario avoids the assembly upload/download loop; it does not make a changed model definition available to Turnkey without updating the server model.

Scenario 3: Debug or test CodeDress outside Turnkey

Use a separate executable test harness when you need fast, repeatable calls to a specific model operation. This is useful for code such as document generation: you can activate an object space, select the target objects, call the operation, and step through the code without navigating a Turnkey UI.

An EcoSpace is the runtime object space that holds model objects after they are read from persistent storage. Turnkey has an EcoSpace internally. Outside Turnkey, your harness must create and activate one.

Create the model-side EcoSpace

1. If your application already has an EcoSpace, such as one created for WPF or WinForms, use that EcoSpace.
2. Otherwise, create an EcoSpace and model project through the Visual Studio project wizard, using the EcoSpaceAndModel project template.
3. If the model is in a separate project, remove the template model file and reference the existing model project instead.
4. Configure the EcoSpace persistence mapper provider (PMP) to access the target MDrivenServer through its WebAPI endpoint. The PMP provides the connection to persisted data.
5. Remove persistence mappers that the harness will not use, such as SQL mappers, and add any assemblies required to build the solution.
6. Build the solution so the EcoSpace recognizes the model packages provided by the referenced model code.

Use the standard MDrivenServer access point when configuring the WebAPI persistence mapper. Keep the server URL and credentials out of shared source files where your development practices require that.

Create a focused executable harness

1. Create a startable project, such as a console, WPF, or WinForms application.
2. Create an instance of the EcoSpace and activate it before accessing model objects.
3. Read or locate the objects that the operation needs.
4. Call the model operation you want to debug.
5. Set breakpoints in its CodeDress implementation and run under the Visual Studio debugger.

Example: a small application can create and activate an EcoSpace, retrieve all instances of a model class, iterate through them, and call one model operation on each instance. Changes saved through that EcoSpace are visible to other applications connected to the same MDrivenServer.

This approach provides local interactive debugging with remote persistence. It also gives automated tests a controlled entry point into CodeDress code.

Use local prototype persistence instead of an MDrivenServer

If you want to remove the MDrivenServer from the debugging loop and use local prototyping XML-based persistence, configure MDrivenServerOverride.xml with the local model path:

<MDrivenServerOverride PrototypeWithMDrivenDesignerInPath="C:\PathToLocalModel.modlr"></MDrivenServerOverride>

In this mode, CodeDress looks for assemblies near the model, at bin/debug and ../bin/debug relative to the model path, rather than in ModelCodeAssemblies.

For a small test model that must reuse assets from a main model, set ExternalAssetsTK to the main model's assets directory:

<MDrivenServerOverride PrototypeWithMDrivenDesignerInPath="C:\temp\DocComp\DocComp.modlr" MDrivenServerPWD="somepwd" ExternalAssetsTK="C:\Users\...\SomeOther_AssetsTK\"></MDrivenServerOverride>

Verify that CodeDress is active

Check the runtime state before assuming that a breakpoint failure is a Visual Studio issue.

• In MDrivenServer, inspect ModelVersionAdministration. After upload, the expected status is CodeFoundAndDressed. Processing can take about a minute. If the status is CodeFoundButOutOfSync, use Documentation:CodeFoundButOutOfSync to resolve the mismatch.
• In a debug-mode Turnkey site, inspect the Developer/ServerInfo page for CodeDress status.
• For runtime diagnostics, see Documentation:Development info in runtime.
• You can add a model operation with no OCL implementation and implement it in C# to return a known value. Without CodeDress, the operation returns its default result; with the matching C# CodeDress implementation loaded, it returns the C# value. This is a direct test that the runtime has dressed the model type.

Troubleshooting

Symptom	Check and correction
Breakpoint is not hit	Confirm that you attached to the w3wp process for the correct application pool, rebuilt the current code, and restarted the process after the build. Confirm that the MDrivenServer model matches the local model when using server-backed scenarios.
Turnkey does not use the new downloaded assets	Delete App_Data/AssetsTKChecksum.xml, end w3wp, and refresh the site. Check the log for extraction and CodeDress messages.
Turnkey cannot create or update runtime files	Grant the IIS application-pool identity Modify access to the log folder, ModelCodeAssemblies, and any local override directory used by the application.
No suitable constructor found or unexpected old code	Check for old MDriven Framework assemblies in the GAC. Remove incompatible framework versions and use the available Clean GAC procedure. Also ensure that the MDriven Framework used to compile the model is compatible with the installed Turnkey version.
CodeDress does not load after moving between runtimes	Check the target framework. .NET Core and .NET Framework binaries are different; build the model for the runtime used by the server.
Dependency/version load conflict	Do not include shared eco.*.dll assemblies with the CodeDress assets. Assembly resolution can prefer an already loaded version, but it cannot intercept a conflicting assembly loaded from the GAC or from beside the CodeDress assembly.

See also

• Documentation:CodeDress
• HowTos:Debug Turnkey Generic Code
• Documentation:Development info in runtime
• Documentation:Code generation
• Documentation:CodeFoundButOutOfSync