We'd like the PluginWorkflowHelper to be able to create PluginTypes in the CRM, so that you don't have to resort to using the PluginRegistrationTool for this. In the SDK, these are created by the PluginRegistrationTool, but map the type metadata in non-trivial ways to the fields.
Currently implemented: the PluginWorkflowHelper can create / update the PluginAssembly in the CRM, which works reasonably well for updating PluginAssemblies, but is a little incomplete, as the corresponding PluginTypes aren't registered. Our lack of awareness also introduces issues - I'm not sure what happens if you update the assembly to remove a type which has dependencies in the CRM (for example).
We need to investigate:
How this mapping from metadata to various PluginType fields work for both Plugins and Custom Workflow types
How to read the types from the parsed .dll without throwing exceptions if it can't locate the referenced assemblies
We'd like the PluginWorkflowHelper to be able to create PluginTypes in the CRM, so that you don't have to resort to using the PluginRegistrationTool for this. In the SDK, these are created by the PluginRegistrationTool, but map the type metadata in non-trivial ways to the fields.
Currently implemented: the PluginWorkflowHelper can create / update the PluginAssembly in the CRM, which works reasonably well for updating PluginAssemblies, but is a little incomplete, as the corresponding PluginTypes aren't registered. Our lack of awareness also introduces issues - I'm not sure what happens if you update the assembly to remove a type which has dependencies in the CRM (for example).
We need to investigate: