Core plugins

These are more like 'modules' of the application. They are projects referenced by the main project and are loaded before dynamic plugins.

Core plugins are the first plugins to be loaded.

Dynamic/Assembly plugins

These are plugins that are completely dynamically loaded. This system is still WIP, but they can do everything a core plugin can do.
Assembly loading doesn't use an AssemblyLoadContext, so there's versioning issues to deal with.

Dynamic plugins are loaded after all core plugins have loaded.

Defining and compiling your plugin

This section will just explain how to actually define a plugin and then compile it. The next section will describe the lifetime and the virtual functions of plugins that you may need to override.

Skip over the "Compiling dynamic plugin" section if you want to create a built-in core plugin.

Defining the class

• All plugin classes must extend the Plugin class.
• The convention is to prefix your class name with "Plugin", even if it ends up looking weird (e.g. PluginMyCoolPlugin). This isn't required, but all current core plugins do this.

Compiling dynamic plugin

• Compile your plugin as usually, it should export to a single DLL file.
• Next, create a folder with the same name as the DLL file (excluding .dll), and place your DLL inside that folder.
• Copy that new folder into the "Plugins" folder of the application, which should be in the same subdirectory as the memory engine EXE file. If there isn't one, then just create one.

For example, if the EXE is located at F:\Programs\MemoryEngine360\MemoryEngine360.exe, then your Plugin DLL would exist at F:\Programs\MemoryEngine360\Plugins\MyCoolPlugin\MyCoolPlugin.dll

Core/built-in plugins

Core plugins compile with the memory engine source, so if you want to create a core plugin (e.g. you want to add connection type, like PS2, to the main source code), then create a fork of memory engine and create a project that will be your core plugin project.

Core plugin projects should go in the "plugins" solution folder within your IDE. I'd recommend looking at MemEngine360.Xbox360XBDM.csproj for how to reference the memory engine and PFX libraries in your new project.

As with dynamic plugins, you still need a class that extends the Plugin class.

"Installing" your core plugin

Go into MemoryEngineApplication.cs and look for the OnSetupApplication method. This is where we register core plugins. You can do preconditional checks to determine if your core plugin can actually be loaded. For example, the XDevkit plugin is only loaded when the OS is windows, since it uses windows-only features (XDevkit COM objects).

For example:

this.PluginLoader.AddCorePlugin(typeof(PluginMyCoolPlugin));

Load errors

The plugins are loaded on application startup. If any error occurred, a dialog will show notifying you of the errors. Check the logs for more info about the errors (Help > Show Logs)

Plugin lifetime

This is the order of API methods that are called into a plugin:

• OnCreated: Invoked just after the constructor is invoked and the PluginLoader and PluginFolder are set.
• OnInitialize: Register your commands and services here.
• GetXamlResources: Add the path of your .axaml files (relative to your plugin project) that should be loaded and added to the application's MergedDictionaries list
• RegisterConfigurations: Register your persistent configs in here
• OnApplicationFullyLoaded: Invoked when the application and plugins are fully initialized and application states are ready.
• OnApplicationExiting: Invoked when the application is about to exit. This is called before persistent configs are saved, so here is where you can synchronize them with the application if you're not already doing it dynamically

Remarks on OnApplicationFullyLoaded: This is where you can register application event handlers, UI controls, context menus or entries, property editor slot controls, and so on.

Supported and unsupported features overview

So far, plugins are able to do some simply things, such as:

• Custom configuration pages and files (using built in persistent storage system)
• Custom data parameters and property editor slots (aka rows)
• Custom commands
• Custom console types
• Custom dialogs and windows
• Adding context menu entries to UIs

... And more. There's still lots that cannot be done yet, such as adding custom panels to the UIs