Training:CodeDress

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 closes the Gap between these 2 strategies.

With CodeDress, you can write strongly typed C# code in Visual Studio and have that code implemented 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 from multiple file types - all in XML and all constructed to be easy to diff and merge with source code tools.

How It Works

The assemblies created with MDriven Framework will be uploaded to the MDrivenServer and 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 a 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, importantly, if you have named your app pools "IIS APPPOOL\xxxxxx" Press the "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 have classes with identities in their UmlElementAttributes that match what Turnkey sees in the model file-based typesystem - then the typesystem is dressed with these classes so that when an object of this type is created (as new objects or as an object read from persistent storage), the class from the assembly is used.

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; you can make use of it in ViewModels and Actions. CodeDress status is included in Developer/ServerInfo page available when the 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, MDrivenServer, MDrivenTurnkey, and MDrivenDesigner.

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

Knowing these 2 limitations, we avoid including 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

Visit the Turnkey debug page for instructions.

Problem-solving

Check the 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 increases the startup speed since file manipulation is slow - but it also solves another problem with IIS which sometimes likes to restart when too 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 fall 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 expected behavior that the App may return error pages 1 to 2 times after a new model upload - this is due to the 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 the code is found and dressed. Sometimes that status is CodeFoundButOutOfSync.

Checking that CodeDress is Active From the Inside of 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; 
}