Training:CodeDress

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.

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 assets that represent this code will be expanded into the site into a directory named ModelCodeAssemblies.

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 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.