Documentation:Debug CodeDress

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.

Scenario 1: Debug Turnkey CodeDress with data from cloud MDrivenServer

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

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

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

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

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:

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

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:

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):

You must be admin and you will get warned:

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

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:

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:

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:

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

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:

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

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:

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: