Dynamic Assemblies [C#]

[Solarion]

Working through this c# course. CIL and Dynamic Assemblies has come up. Could someone be so kind as to give me a real world example of when you have used this?

Here is a link for a quick review

https://www.codeproject.com/articles/362076/understanding-common-intermediate-language-cil

 

[semaphore]

Working through this c# course. CIL and Dynamic Assemblies has come up. Could someone be so kind as to give me a real world example of when you have used this?

Here is a link for a quick review

https://www.codeproject.com/articles/362076/understanding-common-intermediate-language-cil

You will generally never really write in IL, you can however use aspects of IL within C#. I've primarily used it when building dynamic code generation libraries. ORM's also make use of IL, not all but there are a few.

 

[etienne_marais]

Closest I have come to using this is emitting IL using Reflection (thus the actual IL statements were unknown to me).

I used it to dynamically create class definitions (existing only during runtime) with properties unknown at compile time, the idea was to be able to dynamically map a DB table to an object where the properties of the object were set to selected fields/columns' values from the DB.

I am currently refreshing my assembly language skills and hope to move on to IL at some stage to see if optimization or other useful features pop up and if it is really viable. Understanding IL can also help with inspecting disassembly code (available in VS debug sessions for example). I do not think it is something for the average programmer and in my case it is more about curiosity than doing anything advanced or sophisticated (yet may prove useful from time to time).

I do however think that understanding (and knowing) IL will provide insights into the CLR, JIT, Assemblies (and how they interact) and .NET in general just like assembly language provides insight into computer architecture, the operating system and higher level languages where standard approaches are actually a remnant of original programming techniques (yet simplified so to speak) from assembly days.

 

[Solarion]

Thanks etienne that was a lot of effort put in to explaining this. That is very helpful.

 

[etienne_marais]

Just to be sure, MSIL is a beast in its own, but Reflection can roughly be seen on two levels:

1) Getting information about types,objects,methods and variables and also loading assemblies and getting information about assemblies.
2) Emitting code to dynamically create the above (and then some), during runtime.

Using Reflection can be very useful for the first scenario without having any knowledge about MSIL

As an example a bigger program may load modules only applicable to selected clients, a configuration file or a database field may specify which modules are relevant to the client. You can use reflection to dynamically load only the relevant modules for a client, the information (name of assembly, location of library/libraries etc.) about the assemblies need not be hardcoded hence somewhere else in the code it may be of importance which assemblies have been loaded alongside more information about them, again using Reflection.

Another example is passing objects of various types around, and not knowing which accessors (get/set methods they have), Reflection can give you that information and also invoke them, or on a different level checking the modifiers (eg. public/private/protected/internal) of methods in an object to check if you can pass the object somewhere and then be able to invoke those method in the target assembly for instance.

 

[Spacerat]

Just to be sure, MSIL is a beast in its own, but Reflection can roughly be seen on two levels:

1) Getting information about types,objects,methods and variables and also loading assemblies and getting information about assemblies.
2) Emitting code to dynamically create the above (and then some), during runtime.

Using Reflection can be very useful for the first scenario without having any knowledge about MSIL

As an example a bigger program may load modules only applicable to selected clients, a configuration file or a database field may specify which modules are relevant to the client. You can use reflection to dynamically load only the relevant modules for a client, the information (name of assembly, location of library/libraries etc.) about the assemblies need not be hardcoded hence somewhere else in the code it may be of importance which assemblies have been loaded alongside more information about them, again using Reflection.

Another example is passing objects of various types around, and not knowing which accessors (get/set methods they have), Reflection can give you that information and also invoke them, or on a different level checking the modifiers (eg. public/private/protected/internal) of methods in an object to check if you can pass the object somewhere and then be able to invoke those method in the target assembly for instance.

This is particularly of interest in Domain Driven Design. Your domain object has properties that often have private (or no) setters. Domain behaviour is executed by methods. So hydrating a Domain Object from the DB presents a challenge as you cannot have public setters for the properties. I have used above to write some code to use private setters to reinstate a Domain Object's state from the DB

 

[_kabal_]

I personally would favor builder over reflection to instanciate value objects. They are a bit of a pain if you actually have to write then yourself however.
Not sure if C# has any decent tooling to help with that, that integrates well into visual studio? (e.g. Like project Lombok in Java)