Overview

MDriven Framework has always used strongly typed c# code to represent the model.

MDriven Turnkey has used a strict declarative interpretation of the model to create the run-time model that the system follows .

The new functionality dubbed CodeDress close the Gap between these 2 strategies.

With CodeDress you can write strongly typed c# code in Visual Studio and make that code be the implementation in a Turnkey site.

Using CodeDress you will want to manage your source code and model manually with standard tools like GIT or Subversion. MDriven saves the model in 2 different formats the ecomdl format is built of a multiple file types all in xml and all constructed to be easy to diff and merge with source code tools.

This is how it works

The assemblies created with MDriven Framework will be uploaded to the MDrivenServer included as Assets in the Modlr zip file.

The collecting and packing will only happen if you have an <ModelName>_AssetsTK folder next to your model - this is the trigger for any asset modlr file inclusion.

The original assemblies should be on relative path from your model at either bin/debug or at ../bin/debug.

The assets that represent this code will be expanded into the site into a directory named ModelCodeAssemblies.

Note! You need to give your IIS app pool user rights to create files and folders in the web server file system where you have your MDrivenServer. Use Windows folder security, add user on local machine IIS APPPOOL\{app pool name}, For example "IIS APPPOOL\DefaultAppPool" or, important, if you have named you app pools "IIS APPPOOL\xxxxxx" Press "Check names" button. Then OK. Give the app pool user Modify rights.

When a Turnkey typesystem is to be created the ModelCodeAssemblies folder is scanned and if it contains assemblies that has classes that has identities in their UmlElementAttributes that match what Turnkey see in the model file based typesystem - then the type typesystem is dressed with these classes so that when an object of this type is created (as a new objects or a as an object read from persistent storage) the class from the assembly is used.

This is where it can be used

CodeDress is implemented in MDrivenServer and as such you can make use of it in ServerSide ViewModels. CodeDress status can be seen in the MDrivenServer ModelVersionAdministration. See image.

CodeDress is used in Turnkey and as such you can make use of it in ViewModels and Actions. CodeDress status is included in Developer/ServerInfo page available when site is in debug mode.

CodeDress is also implemented in the MDrivenDesigner prototype functionality - including Wecpof.

Complexities associated with CodeDress

When loading assemblies in runtime we must make sure that shared assemblies are of the same version. With shared assemblies I mean all the eco.***.dll assemblies that are part of the framework and will be part of your MDrivenFramework code and will be part of MDrivenServer and MDrivenTurnkey and MDrivenDesigner.

Since versions discrepancies will be common we have implemented the AssmemblyResolve functionality available in .net. This functionality makes it possible for use to prefer the loaded version of an assembly rather than the actually referenced version. This works very good but there are 2 limitations that we need to be aware of: 1 If the assembly version consider to be wrong is available in the GAC - then the AssmemblyResolve will not be able to intercept its loading. 2 if the assembly version consider to be wrong is available next to the your code assembly (same search path) then the AssmemblyResolve will not be able to intercept its loading.

Knowing these 2 limitations we avoid to include the eco.***.dll assemblies in the Modlr file assets. On the server the GAC is rarely a problem - but it may be a problem for the prototyping CodeDress functionality in MDrivenDesigner.

Debugging CodeDress code

Look at the Turnkey debug page for instructions.

Problem solving

Check user rights of the AppPool user

New from 2019-05-26 - we now check the complete ModlrZip 's checksum (aes256) against a file we write on extraction : App_Data/AssetsTKChecksum.xml.

If the checksum is unchanged we skip the AssetsTK extraction and the following mirroring of files to their runtime position. This checksum check increase the startup speed since file manipulation is slow - but it also solves another problem with IIS sometimes like to restart when to many files are touched in the application. Since we normally house 2 apps within the same host-environment (the MDrivenServer and the MDrivenTurnkey-application) it could get into recursion and restart over and over. The checksum fixes this issue. If you still run into problems, look here for more information.

But it is an expected behavior that the App may return error pages 1 to 2 times after new model upload - this is due to unpacking of new and changed assets that may trigger the host to issue a restart.

The MDriven Server status should be CodeFoundAndDressed after upload. It may take a while (a minute or so) after uploading until code is found and dressed. Sometimes that status is CodeFoundButOutOfSync.

Checking that CodeDress is active from inside the model

This example has a function called CheckCodeDressingActive().

It is lacking an implementation in OCL and therefore returns false if called without CodeDress. CodeDress overrides the default functionality and returns true instead.

This is the simple code in C# that returns true when CodeDress is in effect.

public bool CheckCodeDressingActive() 
{  
  return true; 
}