HowTos:Debug Turnkey Generic Code

Debug Turnkey Generic Code

This page was created by Wikiadmin on 2026-07-29. Last edited by Wikiadmin on 2026-07-29.

You can step through CodeDress running in a local MDriven Turnkey application from Visual Studio, whether the runtime data and model come from MDrivenServer or from a local prototype.

Choose a debugging scenario

Turnkey obtains its model and, depending on configuration, its CodeDress assemblies when the application starts. Choose the scenario that gives you the shortest useful edit-build-debug cycle.

Scenario	Use it when	MDrivenServer is used for	Where Turnkey loads CodeDress assemblies
1. Debug against MDrivenServer	You need the data and model currently available on MDrivenServer, and can upload each code change.	Model, data, and CodeDress assemblies.	The assemblies downloaded from MDrivenServer.
2. Debug with local CodeDress assemblies	You need MDrivenServer data and model, but want to test local CodeDress changes without uploading the assemblies for every change.	Model and data.	The folder specified by `CodeDressOverride`.
3. Prototype without MDrivenServer	You want local XML-based persistence and do not want Turnkey to use MDrivenServer.	Not used by Turnkey for this scenario.	Assemblies close to the local model.

For a detailed walkthrough of CodeDress debugging, including debugging CodeDress outside Turnkey with an EcoSpace test harness, see Documentation:Debug CodeDress.

Prepare local Turnkey

Before using any scenario, install and open Turnkey locally as a web site in Visual Studio. Follow HowTos:Development in Visual Studio for the download, Visual Studio Open -> Web Site procedure, SSL configuration, and activation of the local configuration files.

Open the extracted Turnkey Application folder in Visual Studio by choosing Open -> Web Site.
Confirm that the application builds with the same .NET target as the Turnkey installation you are debugging.
Enable SSL for the Application and set its SSL URL as the Application Start Url, as described in HowTos:Development in Visual Studio.
Activate the local configuration by renaming the provided inactive override files to MDrivenServerOverride.xml and TurnkeySettings.xml when required by your local setup.
Ensure that the IIS Application Pool account can access the Turnkey log folder and ModelCodeAssemblies. This access is required when Turnkey writes logs and loads model code.

Scenario 1: Debug CodeDress downloaded from MDrivenServer

Use this scenario when the deployed MDrivenServer holds the model, data, and the CodeDress assemblies you want Turnkey to run.

Configure the MDrivenServer connection

In MDrivenServerOverride.xml, set the MDrivenServer URL as the element value and set the password for the MDrivenServer user in MDrivenServerPWD.

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

Build, upload, restart, and attach

In the Visual Studio project that contains your model and CodeDress, run code generation and build the project.
Upload the current model version to MDrivenServer. Build before uploading so that the matching CodeDress assemblies are available.
Start or refresh the local Turnkey application. At startup, Turnkey fetches the model package and CodeDress assemblies from the configured MDrivenServer.
If Turnkey does not fetch the expected package, stop the IIS worker process (w3wp) for the application and refresh the browser page. This forces Turnkey to start again.
In Visual Studio, choose Debug -> Attach to Process.
Select managed .NET4 code, enable Show processes from all users, and attach to the w3wp process that belongs to the Turnkey Application Pool. Attaching may require administrator rights.
Set a breakpoint in the CodeDress code and perform the UI action that invokes that code. For example, invoke the ViewModel action that calls the method containing your breakpoint.

Force a new model-code fetch

Turnkey may determine that no new package is required and skip updating ModelCodeAssemblies. Check the Turnkey log to confirm whether the fetch was skipped.

To force a new fetch:

Delete wwwroot\test88\App_Data\AssetsTKChecksum.xml in the local Turnkey application.
Stop the relevant w3wp process.
Refresh the Turnkey browser page.
Check the log again to verify that Turnkey loaded the model and CodeDress assemblies.

Scenario 2: Debug local CodeDress while using MDrivenServer data

Use this scenario when you want MDrivenServer to provide the model and data but want Turnkey to load newly built CodeDress assemblies from a local folder. This avoids uploading and downloading the assemblies after every code change.

Configure the local assembly folder

Use the MDrivenServer connection setting from scenario 1 and add CodeDressOverride. Its value must point to the folder containing the current debug assemblies.

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

The IIS Application Pool account must have access to the folder identified by CodeDressOverride.

Debug changes

Make your CodeDress change in Visual Studio.
Build so that the configured override folder contains the new assemblies.
Stop the relevant w3wp process and refresh the Turnkey page.
Attach Visual Studio to that w3wp process.
Repeat the UI action that calls the changed code and step through the breakpoint.

The model version in MDrivenServer and the model used to build the local CodeDress assemblies must match. If they do not match, Turnkey can load incompatible model code.

Scenario 3: Prototype with a local model and XML-based persistence

Use this scenario to remove MDrivenServer from the Turnkey debugging loop and point Turnkey at a local .modlr or .ecomdl model.

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

In this mode, CodeDress searches for assemblies near the model rather than in ModelCodeAssemblies. The searched paths are:

bin\debug, relative to the model path
..\bin\debug, relative to the model path

For concentrated work on a method, document generator, or other CodeDress behavior, consider debugging outside Turnkey instead. Documentation:Debug CodeDress describes how to create and activate an EcoSpace and call the target model method from a small local harness. For example, a harness can activate an EcoSpace, retrieve instances of a model class, and invoke the specific method where you placed a breakpoint.

Reuse assets from another model

A small test model is useful when you are building components in EXT_Components, but copying component assets from the main model creates unnecessary maintenance. Set ExternalAssetsTK to make the test model read Turnkey assets from another asset location.

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

Troubleshoot common debugging problems

Symptom	Likely cause	What to do
Breakpoints are not hit after a code change.	Turnkey is still running an earlier worker process or did not reload the expected assemblies.	Build the code, stop the correct `w3wp` process, refresh the page, and attach Visual Studio again. In scenario 1, delete `AssetsTKChecksum.xml` if Turnkey skipped the download.
Turnkey cannot write logs or load model assemblies.	The Application Pool account lacks access to the log folder or `ModelCodeAssemblies` folder.	Grant the Application Pool account the required access, then restart the worker process.
Visual Studio reports `No suitable constructor found`.	An older framework version is being loaded from the Global Assembly Cache (GAC) by CodeDress.	Uninstall the Framework version that should not be used, then run Clean GAC to remove old loaded versions.
Local CodeDress assemblies do not work with the MDrivenServer model.	The model version used locally differs from the version on MDrivenServer.	Codegen and build the current model, then upload that model when using scenario 1. For scenario 2, ensure the server model and the local build originate from the same model version.
CodeDress does not load after changing between .NET Framework and .NET Core.	.NET Framework and .NET Core binaries are different. A Framework-built model cannot supply CodeDress assemblies for a Core-built server, and the reverse combination also fails.	Create a ModelProject in Visual Studio that targets the required runtime, then build the model with that project so CodeDress loads matching binaries.
Turnkey does not start in IIS.	The application startup error is hidden by IIS error routing or an IIS setting prevents stable startup.	Follow HowTos:Troubleshooting IIS application startup issues to expose detailed errors and review Application Pool settings.

Inspect the running application

When you need runtime information while debugging, use Documentation:Development info in runtime. The /Turnkey/Development endpoint shows the definitions for a selected ViewModel and its Angular widgets. Add debug to a Turnkey AngularApp URL to inspect live AngularJS page data. Serverinfo provides memory and EcoSpace information for the running application.

Browser tools that show where files are loaded from can help you verify that local CSS, scripts, or other development files are being used. Redirect-interception tools can also help when a production OpenID redirect must return to a local debugging URL.

Contents