Debug CodeDress
No edit summary
No edit summary
Line 1: Line 1:
Set up the IIS and install the Turnkey application. You can use the following articles to get help with the installation of IIS and MDrivenTurnkey locally on your machine: [[Development in Visual Studio]], [[Installing MDriven Server on Windows|Installing MDriven Server on Windows.]]
Set up the IIS and install the Turnkey application. You can use the following articles to get help with the installation of IIS and MDrivenTurnkey locally on your machine: [[Development in Visual Studio]], [[Installing MDriven Server on Windows|Installing MDriven Server on Windows.]]
This article describes how to debug Turnkey CodeDress. If you want to debug the CodeDress which executes on MDrivenServer - you can change the model to execute the code on TurnkeyServer for the debug purposes and use the different scenarios described below or install MDrivenServer locally on IIS and use the scenarios below, but instead the Turnkey application use MDrivenServer.


This article describes how to debug Turnkey CodeDress. If you want to debug the CodeDress which executes on MDrivenServer - you can change the model to execute the code on TurnkeyServer for the debug purposes and use the different scenarios described below or install MDrivenServer locally on IIS and use the scenarios below, but instead the Turnkey application use MDrivenServer. 
== Scenario 1: Debug Turnkey CodeDress with data from cloud MDrivenServer ==
== Scenario 1: Debug Turnkey CodeDress with data from cloud MDrivenServer ==
[[File:Image 1.png|none|frame]]
[[File:Image 1.png|none|frame]]

Revision as of 21:53, 29 June 2022

Set up the IIS and install the Turnkey application. You can use the following articles to get help with the installation of IIS and MDrivenTurnkey locally on your machine: Development in Visual Studio, Installing MDriven Server on Windows.

This article describes how to debug Turnkey CodeDress. If you want to debug the CodeDress which executes on MDrivenServer - you can change the model to execute the code on TurnkeyServer for the debug purposes and use the different scenarios described below or install MDrivenServer locally on IIS and use the scenarios below, but instead the Turnkey application use MDrivenServer.

Scenario 1: Debug Turnkey CodeDress with data from cloud MDrivenServer

Image 1.png

Set up your your local turnkey app by copying the template files (green) and rename them to be active(yellow):

Image 2.png

In the MDrivenServerOverride.xml point out the MDrivenServer you want to run towards and its password:

Debugcoderess image 3.png

Verify that is starts, and that it fetch data from the given MDriven Server:

Debugcoderess image 4.png

Make sure your Apppool user has full access to Log catalog and to ModelCodeAssemblies (easiest way give full control to everyone on these):

Debugcoderess image 5.png

As the Turnkey App started it got the zip containing the model and the CodeDress assemblies (your code) from the MDrivenServer.

This fetch is done on start – if you want to restart to fetch to do it again – best way is to kill the w3wp process and refresh turnkey browser:

Debugcoderess image 6.png

But maybe the ModelCodeAssemblies are skipped due to Turnkey finding nothing new – you can see this in the log:

Debugcoderess image 7.png

To force it – delete the wwwroot\test88\App_Data\AssetsTKChecksum.xml file, and restart.

When successful CodeDress has been performed you should see something like this in the log:

Debugcoderess image 8.png

Now you are ready to debug – Start VS and your project holding the model with CodeDress.

Make sure you codegen, then build then upload the current version of the model (build first to ensure you have the correct assemblies available to upload).

Restart your turnkey app (kill w3wp process and refresh browser app-page to force it to start)

In VS do Debug/AttachToProcess – Select managed .NET4 code, Check the Show processes from all users – attach w3wp (the one corresponding to your apppool):

Debugcoderess image 9.png

You must be admin and you will get warned:

Debugcoderess image 10.png

When your web UI calls your model code your breakpoints will be hit:

Debugcoderess image 11.png

Scenario 2: Debug Turnkey CodeDress without roundtripping code changes to MDrivenServer

So far soo good – but this still roundtrips the assemblies up to the MDrivenServer, and downloads them back into your local turnkey app. It would be good if we could tell Turnkey to fetch CodeDress assemblies from somewhere closer.

To set this up amend the MDrivenServerOverride setting with a CodeDressOverride attribute pointing out where you have fresh CodeDress assemblies:

Debugcoderess image 12.png

Make sure to make this location accessible for your apppool account (just give full access to everyone)

Make code changes, Kill w3wp, refresh page – attach w3wp – debug new code without sending code to cloud MDrivenServer.

Scenario 3: Debug/Test CodeDress outside of Turnkey

When you need to focus on a piece of code and loop over it many times you will benefit of the smallest possible round trip to make it work as you want – for this the VS edit and continue is fantastic.

You may also want your code access from automated tests – and this can follow the same principle (if your automated test need access to data in an MDrivenServer).

For this you need to define an EcoSpace – this is what Turnkey holds internally and is where the objects live in runtime once they are re-animated from persistent storage (from the data in the db).

If your system is hybrid and already use WPF or Winforms or anything else that has forced you to create an Ecospace already – then you should probably use that. But if not you create easiest by the project wizard – new project – EcoProject1.EcoSpaceAndModel. You will get this:

Debugcoderess image 13.png

If you have a separate Model project already you can delete the ecomdl – and instead reference that project.

The green is called a PersistenceMapperProvider or PMP for short. This is what provides the connection to where the persisted data exists. There are many different ways to access the data – but we will focus on accessing the data via WebAPI from an MDrivenServer.

We set this up like this in the constructor of the PMP:

Debugcoderess image 14.png

The yellow is your target MDrivenServer, the green is the standard access point.

As this is the only PersistenceMapper-Client we will use we can remove the others provided by the template

Debugcoderess image 15.png

We now build our solution (add any missing assemblies – remove SQL assemblies since we will not use). Having built – The EcoSpace will detect the model-packages found in your code:

Debugcoderess image 16.png

What this widget actually does is adding the package reference in code in your EcoSpace:

Debugcoderess image 17.png

We now need to create an EcoSpace instance, and Activate it to connect it to the MDrivenServer.

Use your favorite startable project type – like  console app, WPF app, WinForms app or what you have and do something like this:

Debugcoderess image 18.png
Debugcoderess image 19.png

You will be able to see saved changes in any other app connected to the same MDrivenServer

And now you can take full advantage of VS edit and continue while stepping your code:

Debugcoderess image 20.png

Scenario 4: Debug MDrivenServer CodeDress connected to cloud DB

This page was edited 48 days ago on 02/10/2024. What links here