The Different Scenarios for Debugging Turnkey Generic Code

1. You have the MDrivenServer stable and you want to step through Turnkey-generic code
2. Debug CodeDress code from the model or you have the MDrivenServer stable and want to step through Turnkey-generic code
3. You want to debug toward local prototyping XML-based persistence, cutting MDrivenServer out of the equation

A walk-through article complementing this Wiki post is available here: https://blog.mdriven.net/debug-codedress-turnkey-locally/

Starting Turnkey Locally

Please look here for instructions on downloading, unpacking, and opening Turnkey as a Web site in Visual Studio.

Debugging

1: MDrivenServer is stable and you want to step through Turnkey-generic code

Use MDrivenServerOverride.xml with the setting:

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

2: Debug CodeDress code from the model or you have the MDrivenServer stable and you want to step through Turnkey-generic code

Make sure you have the same model version in the MDrivenServer as you have locally in Visual Studio. Use MDrivenServerOverride.xml with the setting:

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

3: You want to debug toward local prototyping XML-based persistence, cutting MDrivenServer out of the equation

Note that for this option CodeDress will always try to find assemblies close to the model rather than in ModelCodeAssemblies. The tried paths for assemblies are "bin/debug" and "../bin/debug" (relative to the model path): Use MDrivenServerOverride.xml with the setting:

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

When you debug and build components (EXT_Components) its practical to have a very small test-case-model - but that would force you to copy component files from the main model. Use the setting ExternalAssetsTK to stear you test model to read assets from your main model

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

All steps require Turnkey generic code access to work fully but can be used partially by opening Turnkey local installations in Visual Studio as a website.

If you want to see the status of a running Turnkey app, look here: Serverinfo

Problem-solving

If you run into problems, here are some possible situations and how to correct them:

• Make sure you have the same installed version of TK and the installed Framework in VS. If you uninstall the Framework, try Clean GAC to be sure you don't load old versions.
• Exception in VS with No suitable constructor found
• Old versions in the GAC get loaded from your CodeDress. Uninstall Framework and then Clean GAC

Other Tips and Tricks

• There are many Chrome plugins to intercept where files are loaded from -> great when you want your app to grab stuff from your development folder to avoid reloading the CSS all the time.
• There are Chrome plugins for intercepting redirects -> great when you have an OpenID provider set up for production but need to debug locally - then catch the OpenID redirect back to your localhost.

.net Framework vs .net Core

The binaries for .net Core and .net Framework are different and CodeDress from a core-built-server with a Framework-built model will not work. Create a new ModelProject in VS that targets .net Core and build the model with that to get CodeDress to load.