Skip to main content

Extension load mechanism

background​

In V2.0, we changed the extension loading mechanism to solve the following problems with V1.1 extensions.

  • Newer versions of libraries than those referenced by Next Design cannot be loaded. Therefore, extensions could not use functions provided by new versions of libraries provided by 3rd parties.
  • Multiple extensions cannot load different versions of the same library. Therefore, it was necessary to align the version of the library for all extensions installed.
  • Extensions containing native libraries cannot be loaded. As a result, we were unable to distribute extensions that depended on native libraries.

Changes to the extension loading mechanism​

It is now possible to use different versions of the library for each extension​

In V2.0, it was changed so that the library is loaded in a different area for each extension. However, regarding the library referenced by Next Design, if the version of the library referenced by Next Design is newer or the version is the same, the extension will not load the new library, and Next Prioritize libraries already loaded in the Design body.
This is for the following reasons.

  • Suppress the memory size allocated for the library load area
  • Ensures the operation of the Next Design body side
  • Suppress interface inconsistency due to data exchange between Next Design itself and extensions

Effect of change

  • With V2.0 extension, you can use newer versions of libraries than those referenced by Next Design itself.
note
  • For example, V1.1 extensions could not use newer versions of libraries than the Microsoft.WindowsAPICodePack referenced by Next Design itself.
  • With V2.0 extension, you can use newer versions of libraries than Microsoft.WindowsAPICodePack that Next Design refers to.
  • With V2.0 extensions, multiple extensions can use the same library with different versions.
note
  • For example, if one extension A uses version 4.7.1 of System.Text.Json, in V1.1 another extension B uses a new version 5.0 of System.Text.Json .2` was not available.
  • In V2.0, a new version 5.0.2 of System.Text.Json is available in another extension B. In this case, extension A uses API version 4.7.1 and extension B uses API version 5.0.2 respectively.

Changed how extension dependencies are resolved​

In V2.0, we have changed how extension dependencies are resolved.
Assembly metadata description files (*.deps.json files) are used to resolve the locations of dependent libraries.
Also, it has been changed so that even if the dependent library is a native library, it can be recognized correctly.

Effect of change

  • Assembly metadata descriptions allow extensions to customize the configuration of dependent libraries.
tip
  • If the dependent library is resolved using the NuGet package management function, the assembly metadata description file (*.deps.json file) is automatically generated at build time.
  • Therefore, for V2.0 extensions, it is recommended to resolve dependent libraries using the NuGet package management feature.
  • You can distribute extensions that depend on native libraries.
note
  • In V1.1, extensions with native libraries placed under the extension folder could not be loaded.
  • With V2.0, you can deploy extensions that rely on native libraries by describing assembly metadata.
  • Also, even if "the dependent native library is different" due to the difference in OS or CPU, in order to solve it when running the extension, for example, one native library for win-x64 and win-x86 Can be bundled with extensions.

Changed handling of static variables in libraries referenced by multiple extensions​

In V2.0, static variables are handled differently than in V1.1 because libraries are loaded in different areas for each extension.

  • In V1.1 static variables were shared between multiple extensions.
  • Static variables are not shared between multiple extensions in V2.0. Therefore static variables cannot be used to share information between extensions.
note
  • For example, in V1.1 this class variable is shared by all extensions if the code is:
  • However, in V2.0, memory management is different for each extension, so class variables are limited to extensions only.
public class SomeClass
{
    private static IDictionary<string, object> _SomeDictionary = new Dictionary<string, object>();
}

Changes and precautions for extension distribution procedure​

Along with the change in the extension loading mechanism of V2.0, the configuration of the distributed extension will also change.

Extension folder structure​

In V2.0, in addition to the manifest file, extension main library and dependent libraries, the assembly metadata description file (*.deps.json file) is placed in the extension distribution folder.

+ ${extension folder}/
  - manifest.json
  - ${extension body library name}.dll
  - ${extension body library name}.deps.json
  - ${extension dependent library name}.dll
  - ...

Assembly metadata description file
When you build an extension with dotnet build, it is automatically created in the output folder of the build result. See below for details.

tip
  • When distributing your extension, place the generated *.deps.json file in your extension folder.
  • If it is not placed, it may fail to load the library that the extension depends on.

Collect dependent libraries
dotnet publish can collect extension dependencies into an output folder. See below for details.

tip
  • dotnet publish collects all dependent libraries.
  • If the extension uses a library that also references the Next Design main body, if the library is not a newer version than the main body, it can be removed from the package when distributing the extension to reduce the package size.

Placement of internationalized resource DLLs​

C# standard localization can be used for DLL-type extensions.

  • If an extension (and its dependent library) supports internationalization using string resources, a library (*.resources.dll) containing resource information for each language will be generated in the output folder.
  • When distributing your extension, place those libraries in the extension folder along with the folder structure.
+ ${extension folder}/
  +en/
    - ${extension body library name}.resources.dll
  +fr/
    - ${extension body library name}.resources.dll
  - manifest.json
  - ${extension body library name}.dll
  - ${extension body library name}.deps.json
  - ${extension dependent library name}.dll
  - ...

Deploying Native Libraries​

With V2.0 you can now use native libraries for extensions.

  • If an extension (and its dependent libraries) depends on a native library, the native library for each runtime environment will be output to the output folder.
  • When distributing your extension, place those libraries in the extension folder along with the folder structure.
+ ${extension folder}/
  + runtimes/
    + win-x64/
      - ${native library name}.dll
    + win-x86/
      - ${native library name}.dll
  - manifest.json
  - ${extension body library name}.dll
  - ${extension body library name}.deps.json
  - ${extension dependent library name}.dll
  - ...

Limitations​

Conflict with library referenced by Next Design body​

Libraries with older versions than those referenced by Next Design will not be loaded. The new version of the library referenced by the body is used. So when an extension utilizes the same but older versions of the assemblies in the same folder as the Next Design exe, the extension fails to activate if backward compatibility is not guaranteed between those assemblies, or An error will occur during execution.

tip
  • For example, if an extension built with the old NextDesign.Core refers to an obsolete interface in the new NextDesign.Core, an error will occur in the new Next Design because the interface cannot be resolved.

Constraints for Extensions Referencing Native Libraries​

Due to .NET limitations, it may not be possible to resolve where native libraries are located.

  • Load native library by NativeLibrary.Load() is requested, it cannot be resolved with the new extension loading mechanism in V2.0.
  • Therefore, if the native library is loaded with the above method, the corresponding library must be placed in a location that can be loaded with NativeLibrary.Load().

Native libraries that fall under the above known limitations at this time

  • SQLite native library (e_sqlite3.dll) used in EFCore is applicable.
    • Next Design V2.0 includes EFCore 3.1 series native library to alleviate the above restrictions.
    • Therefore, the operation of extensions that depend on versions other than EFCore 3.1 series is not guaranteed.

Constraints on Temporary Assembly File Generation​

If an extension uses functions that require the generation of temporary assembly files at runtime, the extension may not work properly because the extension loading mechanism cannot identify the storage location of those assembly files. Choose an implementation method that avoids the generation of temporary assembly files according to the information provided by the developers about the features you use.

Last updated on