AOP in. Net: Analysis of postsharp principles

I am studying AOP again this time, and I am no longer interested in the Dynamic Injection principles. I want to study the Static injection AOP, first of all, postsharp.

PS: routing and ASP. NET MVCArticleTemporarily put it

Static injection refers to compiledProgramInject il into a type or method in a set (preferably called an Assembly set)Code(Instead of injecting at the runtime of the Assembly), the injection is called "Join-point ".

There are many tools that can read and write assembly and inject il code, such as a plug-in of reflector. However, postsharp injects il into the Assembly when you compile an assembly.

Postsharp is not like resharp. It is not a plug-in of Vs, and it does not modify the code in the editor.

So how does postsharp work?

How does it insert itself into the compilation process of the compiler?

We all know that vs is used to execute the generation process through msbicould. Therefore, postsharp inserts itself into the generation process as a series of build tasks.

Then it modifies the default configuration of Vs to call msbicould. So that the build command of vs executes the task specified by it. The following figure illustrates the principles of postsharp:

But to really understand the principle of Static injection, to understand il reading and writing, you also need to have a deep understanding of. Net assembly, CLI and Il.

To truly understand how postsharp works, you must understand msbuild and how to execute custom build tasks.

There are a lot of things vs has done for us, so we don't know, there are many developers now think that. Net assembly is a hosted DLL file!

Next I will write some articles about this.

However, you can find the msbuild document in the following two links:

Http://msdn.microsoft.com/zh-cn/library/wea2sca5.aspx

Http://msdn.microsoft.com/zh-cn/library/0k6kkbsd.aspx

Reference a section in the postsharp document:

 

Difference between the postsharp code object model and system. Reflection

Postsharp uses the entities defined in the specifications of the common language infrastructure (CLI). However, developers are more familiar with the conceptsSystem. Reflection. They shocould be awareSystem. ReflectionIncludes great simplifications with respect to CLI specifications. cli is module oriented. A module is an atomic artifact that can bind to other modules to form complete applications. In order to refer to types definedOutsideThe current module, one usesReferences. By contrast,System. ReflectionLives inApplicationUniverse where all references between modules are already resolved. In CLI and in postsharp, references are explicitly represented as separate entities. But inSystem. Reflection, There is simply no concept of reference.

Modules

Modules (moduledeclaration) are atomic artifacts (I. e. They cannot be separated in smaller units).. Net modules are in fact portable executables (PE) Just like native libraries and executables.

Assemblies

There is a common confusion about assemblies. an assembly, as indicated by its name, is a set of assembled modules and other files. so an assembly can be composed of modules and even of unmanaged modules! It is a common mistake and misleading to consider that an assembly is composed of a single file.

What defines intrinsically the assembly is itsAssembly manifest(Assemblymanifestdeclaration ). the manifest is composed of a list of references to modules and external assemblies, and of a list of exported types. the assembly manifest is contained in 'prinal al' managed module of the Assembly (and not in a separate XML file, as claims another frequent mistake ).

So the assembly manifest (assemblymanifestdeclaration) is contained in a module (moduledeclaration); it contains references to external modules (modulerefdeclaration) and external assemblies (assemblyrefdeclaration ).

So let's summarize:

• Modules, not assemblies, are the real atoms.
• Assemblies are composed of modules (managed or unmanaged executables ).
• Assemblies are defined by an assembly manifest.
• The assembly manifest is stored in a managed module.
• A managed module may, but is not required to, contain an assembly manifest.

Postsharp makes a difference between an Assembly and an assembly manifest. The assemblyenvelope class encapsulates the Assembly understood as a collection of modules. The specified class encapsulates the manifest; it does not contain modulesIs containedBy a module. Where assemblymanifestdeclaration contains a collectionReferencesTo modules, assemblyenvelope contain modules in themselves.

Domains

Postsharp domains (domain) are similar to the. NET classAppdomain. Domains are contexts in which references between assemblies are solved. Just as in. net, postsharp assemblies are always loaded in a domain. postsharp allows between domains to be loaded paralely, evenAppdomain.

The base of the object tree is the moduledeclaration type. Since postsharp is module-oriented, everything is contained in the module even the assembly manifest.