Skip to main content

V2.0 extension load mechanism

Background

In V2.0, the extension loading mechanism has been changed to address the following issues with V1.1 extensions:

  • Unable to load a newer version of the library referenced by the Next Design body. As a result, the extension did not take advantage of the functionality provided by the new version of the library provided by 3rd Party.
  • Multiple extensions cannot load different versions of the same library. Therefore, it was necessary to have the same version of the library for all the extensions to be installed.
  • Extensions containing native libraries cannot be loaded. Therefore, it was not possible to distribute extensions that depend on the native library.

Changes in the extension load mechanism

Allowed to use different versions of the library for each extension

In V2.0, it has been changed to load the library in different areas for each extension. However, for the library referenced by the Next Design body, only if the library referenced by the Next Design body has a newer version or the same version, the extension does not load a new library and Next Priority is given to libraries that have already been loaded in Design itself. This is due to the following reasons.

  • Suppress the memory size reserved for the library load area
  • Guarantee the operation of the Next Design main unit
  • Suppress interface inconsistency due to data exchange between the Next Design main unit and the extension

Effect of change

  • V2.0 extensions can use newer versions of libraries than the libraries referenced by Next Design itself.
note
  • For example, the V1.1 extension did not have access to a newer version of the library than the Microsoft.WindowsAPICodePack referenced by Next Design itself.
  • The V2.0 extension makes available a newer version of the library than the Microsoft.WindowsAPICodePack referenced by Next Design itself.
  • V2.0 extensions allow multiple extensions to take advantage of different versions of the same library.
note
  • For example, if one extension A uses version 4.7.1 of System.Text.Json, then in V1.1 another extension B uses the new version 5.0 of System.Text.Json. .2 was not available.
  • In V2.0, another extension B will be available with the new version 5.0.2 of System.Text.Json. In this case, extension A uses version 4.7.1 API and extension B uses version 5.0.2 API, respectively.

Changed the solution for extension dependent libraries

In V2.0, we changed the solution of the location of the extension's dependent library. Use the assembly metadata description file (* .deps.json file) to resolve the location of dependent libraries. Also, I changed it so that it can be recognized correctly even if the dependent library is a native library.

Effect of change

  • By writing assembly metadata, the placement configuration of dependent libraries can be customized on the extension side.
tip
  • If the dependent libraries are resolved using the NuGet package management feature, the assembly metadata description file (* .deps.json file) is automatically generated at build time.
  • Therefore, it is recommended to use the NuGet package management function to resolve dependent libraries in V2.0 extensions.
  • 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.
  • In V2.0, you can place extensions that depend on native libraries by writing assembly metadata.
  • Also, even if "the dependent native libraries are different" due to the difference in OS and CPU, in order to solve it at the time of extension execution, for example, one native library for win-x64 and one for win-x86. Can be included in the extension.

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

In V2.0, static variables are treated differently from V1.1 because the library is loaded in different areas for each extension.

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

Changes/Notes on extension distribution procedure

With the change of the extension loading mechanism of V2.0, the configuration of the extension to be distributed will also change.

Extension folder structure

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

+ $ {Extension folder} /
  - representation.json
  - $ {extension body library name} .dll
  - $ {extension body library name} .deps.json
  - $ {extension dependent library} .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 the extension, place the generated * .deps.json file in the extension folder.
  • If not deployed, the extension may fail to load the dependent libraries.

Collection of dependent libraries You can collect the extension's dependent libraries in the output folder with dotnet publish. See below for details.

tip
  • dotnet publish collects all dependent libraries.
  • If the extension uses a library that also references the main body of Next Design, you can reduce the package size by removing it from the package when the extension was distributed, unless the library is a newer version than the main body.

Placement of internationalized resource DLLs

For DLL-based extensions, the C# standard Localization (https://docs.microsoft.com/ja-jp/dotnet/core/extensions/localization) is available.

  • If the extension (and its dependent libraries) supports internationalization using string resources, a library (* .resources.dll) containing resource information for each language will be generated in the output folder.
  • When distributing extensions, 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
  - representation.json
  - $ {extension body library name} .dll
  - $ {extension body library name} .deps.json
  - $ {extension dependent library} .dll
  โ€•โ€• ใƒป ใƒป ใƒป ใƒป

Native library placement

In V2.0, native libraries are available for extensions.

  • If the extension (and its dependent libraries) depends on the native library, the native library for each runtime environment will be output to the output folder.
  • When distributing extensions, 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
  - representation.json
  - $ {extension body library name} .dll
  - $ {extension body library name} .deps.json
  - $ {extension dependent library} .dll
  โ€•โ€• ใƒป ใƒป ใƒป ใƒป

Limitations

Conflict with the library referenced by Next Design

Libraries older than the library referenced by Next Design itself will not be loaded. The new version of the library referenced by the main unit will be used. Therefore, when an extension uses an older version of an assembly that is the same as the assembly in the same folder as the Next Design exe, activation of the extension fails or fails if backward compatibility is not guaranteed between those assemblies. An error will occur at runtime.

tip
  • For example, if an extension built with the old NextDesign.Core references an obsolete interface in the new NextDesign.Core, the new Next Design will fail because it cannot resolve the interface.

Extension constraints that reference native libraries

Due to .NET Core restrictions, it may not be possible to resolve the location of native libraries.

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

Native libraries that meet the above known restrictions at this time

  • This applies to the SQLite native library (e_sqlite3.dll) used in EFCore.
    • Next Design V2.0 includes a native library of EFCore 3.1 series to relax 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 a function that requires temporary assembly files to be generated 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