PluginRequirement
ReferencesConstructors
PluginRequirement
#| id (Guid) | Plugin id. |
| name (string) | Plugin name as it read when the document was saved. |
| version (Version) | Plugin version as it read when the document was saved. |
| core (bool) | True if the plugin shipped with Grasshopper. |
| objects (Guid[]) | IoIds of the object types this plugin contributed to the document. |
Properties
Core
#Id
#Installed
#IsOutdated
#This deliberately says nothing about which build is newer. What matters is that some types will not resolve, and there is no fixing that from here: Rhino cannot hold two builds of one assembly at once and the loaded one has already won, so any change of version needs the package manager and a restart.
Never true for a core plugin, by the reasoning in IsSatisfied.
IsSatisfied
#A loaded core plugin always counts as satisfied. Grasshopper's own libraries are not something the user installs, chooses a version of, or can be expected to do anything about, so a shortfall there is never worth putting in front of them — see IsOutdated.
Name
#Objects
#Unresolved
#This is the honest test of whether a document can be read, and it is why the manifest records object ids rather than trusting a version number. An installed plugin older than the one a file was saved with will be missing the types added since; a version comparison would only guess at that, whereas asking which ids resolve answers it. It also catches the reverse, where a newer plugin has dropped a type an old file still uses.
The question is put to IO.ResolveType(Guid) rather than to ObjectProxies.IsKnownId(Guid), because that is the lookup deserialisation itself performs. The proxy table is a strict subset of it — a type whose proxy failed to register, for want of a usable constructor say, is still perfectly restorable — so asking the proxies would invent missing types which are not missing at all.