Orchard dynamic compilation Mechanism

ArticleDirectory

• Overview
• Found
• Example
• Loader Selection
• Example
• Reference Parsing
• Configuration change detection
• "~ /App_data/dependencies. xml "File
• References

As an extensible CMS system, orchard needs to load some modules or topics (collectively referred to as extensions) at runtime ). Since orchard 0.5, we have been committed to making it easier to install and upgrade these extensions. Orchard and any other ASP. net mvc application Program Can be compiled in the Visual Studio environment. However, orchard also provides another module loading policy. For example, it allows the module DLL to be deployed in the bin directory of the website. In addition, orchard can dynamically follow the module Source code To compile the module. In this way, you can deploy DLL files flexibly and compile the modified Module source at any time without the Visual Studio environment. Code . This is a bit similar to the "app_code" folder of ASP. NET, but Orchard supports more such folders. This article describes how orchard loads modules and dynamically compiles them.

 

Overview when an orchard application is started, the orchard framework (which is specifically the responsibility of the extensionloadercoordinator class) needs to understand the modules installed and activate them (that is, the DLL for loading these modules ). In more detail, this process is divided into three stages: 1. Discovery: Find out which modules are available on the website. 2. Activation: determine the policies used to activate or load each module. 3. Reference parsing: it is clear that the Assembly needs to be referenced to activate these modules. This phase of technology is part of the "activation" phase, but it is easier to think about the issue of reference parsing as a separate part. Once a module is positively activated, it will further check to detect and enable individual features, but this is not the topic to be discussed in this article. It is found that the available modules in orchardare obtained by querying the “le.txt file under some folders. The following lists the default query folders:

"~ /Modules "folder

"~ The/modules folder contains most orchard modules. Orchard stipulates that each module is stored in a sub-folder named <modulename> and contains a “le.txt file. The packaging, publishing, and analysis modules are only the modules in this folder. This folder is the folder for customizing the orchard module.

"~ /Core "folder

"~ The/Core folder contains the most core modules of orchard, which are provided by the orchard team. Users usually do not add new modules here.

"~ /Themes "folder

"~ The/themes folder contains the orchard topic. As a dynamic compilation, themes are almost processed as modules, and there is no code (bin and. csproj files) for processing topics ). For the rest of this article, when we mention "modules", it also applies to "themes ".

Note :"~ /"Indicates the root directory of the website.

The following is an orchard installation instance, which contains six extensions: two core modules: Common and localization, and two application modules: Foo and bar ", there are also two themes: "T1" and "T2 ".

 rootfolder core common module.txt <=" common "module from" core "localization module.txt <=" localization "module from" core "modules Foo module.txt <=" foo "module bar module.txt <= "bar" module themes T2 theme.txt <= "T1" theme T2 theme.txt <= "T2" theme 

 

Activate

Orchardcollects all module.txt files from the discovery dimension. orchard loads these modules in memory using different policies (or "module loaders. Internally, the module loading behavior is an activity. Input “le.txt file and return a "system. Type" list. Note that this is different from returning a "system. assembly list, because orchard supports an assembly containing multiple modules, such as: "orchard. core. dll contains about 10 orchard modules. Orchard currently implements the following module loading policies (loaders ): "Referenced module" Loaders This loader is in Check the assembly corresponding to the module name in the "“le.txt file in the/bin1_directory. If the Assembly exists, it loads and returns all types of the modified assembly. This loader is used when all modules are pre-compiled and Their DLL is stored in /Bin directory, which is a typical "Asp.net MVC" application method. "Core module" Loaders If “le.txt "file comes from "~ /Core "folder, the core module loader will return all types from Orchard. Core. dll," orchard. Core. <modulemame> "namespace. Orchard. Core. dll is a special assembly that contains the orchard core module and provides some basic functions based on the orchard framework. "Pre-compiled module" Loader If “le.txt "file comes from "~ /Modules "folder, the pre-compiled module loader will be in" ~ /Modules/<modulename>/bin "to find the Assembly named <modulemame>. If this file exists, it will be copied "~ /App_data/dependencies "folder, which is a special folder for Asp.net search" ~ /Bin "outside the folder. "Dynamic module" Loaders If “le.txt "file comes from "~ /Modules "folder, the dynamic module loader will be in" ~ /Modules/<modulename>/bin "to find the. csproj file. If this file exists, the loader will use the orchard compilation manager to compile the Assembly according to the. csproj file and return all types of the modified assembly. Note: This loader has only one loader during system execution, which is often called "dynamic compilation ". In fact, this is optional. If all modules are pre-compiled, you can also choose other loaders. Since there may be more than one loader capable of loading a specified module, how does orchard make the right choice? Each loader can return the "last modification time" of the corresponding module. For Multiple loaders, orhcard determines the type of loader to be used based on the latest "last modification time. For example, a module contains all the source files including the. csporj file and the DLL that has been compiled into the bin directory. When the module is loaded for the first time, orchard will load the assembly in the bin directory, and the source code will be less than the new one in the Assembly. However, if the source code has changed, the "last modification time" returned by the dynamic module loader is greater than the "last modification time" for loading the assembly in the bin directory, orchard uses the dynamic module loader. It is worth noting that such differences only exist in "~ /Modules "the module in the folder, because "~ The modules in the/core "folder only use the loader of the core modules. Example

Rootfolder bin orchard. web. DLL orchard. core. DLL Foo. DLL core common <= "core module" loader module.txt localization <= "core module" loader module.txt modules Foo <= "reference module" Loader (because "~ /Bin/Foo. dll "file exists) module.txt bar <=" precompiled module "Loader (because "~ /Modules/BAR/bin/bar. dll "file exists) Bin bar. dll module.txt Baz <=" dynamic module "Loader (because "~ /Modules/Baz. csproj "file exists) controller bazcontroler. CS Baz. csproj module.txt

The reference parsing dynamic module loader searches for other assembly files referenced by the module in the bin directory of the module based on the references node in the. csproj file, and copies them "~ /App_data/dependencies "folder. Note that the DLL referenced by the module must be copied to the bin directory of the module, and the reference location must also be in this directory. Configuration change detection as described above, loads modules when an application starts. However, once the application is started, changes may still occur at any time. For example, the source code of a module may be updated manually, and a module may be installed or deleted on the website. To detect these changes, orchard needs to provide a mechanism to "Monitor" potential changes and notify the module loader when changes occur. When changes are detected, the configurations of the current module will be discarded and re-reviewed, loaded, and activated at the same time, just as the application restarts. In some cases, these changes require an Asp.net appdomain to be restarted (for example, an Assembly of a new version of the module needs to be loaded ), orchard will detect this situation and restart an Asp.net appdomain. "~ /App_data/dependencies. xml "File

This file contains the list of modules, loaders, and modules referenced when the application was last loaded successfully. Check the content of this file for debugging and check whether the corresponding DLL is loaded.

 

References

Http://www.orchardproject.net/docs/Orchard-module-loader-and-dynamic-compilation.ashx