PluginServer

Gets an enumerator for all the core component library assemblies. This property iterates over all RHP files inside the plugin components folder, whether or not they were put there by the Grasshopper installer.

Enumerate all custom plugin files.

Gets whether a plugin is currently in the process of being loaded.

The load lock is held for the entire duration of a plugin load, so a lock which cannot be taken right now means another thread is busy loading. Taking the lock the usual way would block until that load completes, so this probes the lock instead of waiting on it. On the loading thread itself the lock is re-entrant and the loading set is consulted directly.

Gets how far the startup sequence has progressed. Plugins loaded after the startup sequence do not affect this, see PluginLoaded for those.

Gets the current state of the plugin server. The state is immutable and should never be cached, but always retrieved anew.

Enumerate all 3rd party plugin files.

Enumerate over all plugins that Grasshopper would load if it were asked now to do so. This list is not necessarily consistent with the number of plugins that Grasshopper loaded when it started.

Describe what uninstalling a plugin would actually do, for putting to the user before it happens.

The two kinds of installation carry very different risk. A custom plugin is no more than an entry on a list of files to load, so removing it changes nothing on disk and can be undone by picking the same file again. A Yak package is files, every version of them, and getting them back means downloading them again — assuming the server still has them.

Find which plugin provides the given document object. It is possible that an object is not associated with any plugin.

Find which plugin provides the given document object. It is possible that an object is not associated with any plugin.

Forget a scoped potential plugin.

Add a custom component assembly. This is typically used only for those plugins which are not installed through regular channels, such as plugins being locally developed or debugged.

Try and load all scoped plugins.

Load a plugin assembly into the framework.

Attempt to load a plugin from a file.

Remove a failed plugin from the list.

Add all custom selected plugin files to the scoped list.

Scope a potential plugin. This always happens before a plugin is actually loaded.

Add all standard plugins to the scoped list.

Add all yak package installed plugins to the scoped list.

Remove a custom component assembly. This is typically used only for those plugins which are not installed through regular channels, such as plugins being locally developed or debugged.

Uninstall a plugin, whichever way it was installed.

A custom plugin is only ever an entry on a list of files to load, so removing the entry is the whole job. A Yak plugin is a package on disk, and getting rid of it means deleting that — which Windows will not do while the assembly is loaded, so whatever will not go now is put on FleetingPlugins' removal ledger and dealt with at the next startup.

Raised once for each stage of the startup sequence, when it is reached. A late subscriber should check LoadState first; both the check and the subscription are safe on the UI thread, which is where the stages are reached.

Raised when a plugin fails to load.

Raised when a scoped plugin is forgotten during the runtime of Grasshopper.

Raised when a plugin successfully loads.

Raised just before a plugin starts getting loaded.

Raised when a loaded or failed plugin is removed during the runtime of Grasshopper.

Raised when a new plugin is discovered during the runtime of Grasshopper.