Is it possible to create a plugin that replaces / overrides a plugin in clear canvas already?

While I can build clear canvas from scratch, it seems like an overkill if all i want to do is swap out a plugin.

Hi, you can safely remove any of the plugins in the 'plugins' folder and replace them with your own. You only need to make sure that you don't remove anything that is required by any of the remaining plugins.

Hope this helps,
Stewart

Hi, just a further clarification:

- If you want your plugins to work with an existing version of CC (1.0 or 1.1 for example) then you must build your plugins with the corresponding CC SDK. Also, your plugins will need to be strong-name signed because official builds of CC are strong name signed.
- My previous point about removing/replacing plugins may not have been totally clear. Because of .NET versioning, if you remove/replace a plugin, you must also remove any plugins that depended on it. So, for example, if you wanted to replace the CC.ImageViewer plugin, you can't simply replace it; you would need to either remove/replace/rewrite all the plugins that depend on it as well. Some of the 'tools' plugins (CC.ImageViewer.Tools.Standard, for example) are very easy to replace as they have no dependencies other than CC.ImageViewer and the other core plugins (like CC.Common and CC.Desktop).

-S

I guess I should have been a little more clear..

well im refering to replacing a specific tool in plugin that already exists in a clear canvas dll

Rather than completely rebuilding clear canvas to change 5 lines of code, Id like to be able to override the tool by perhaps specifying a new attribute on my new tool.

perhaps somethig like:

[UseInPlaceof(CC.ImageViewer.ToolX)]
class MyBetterTool {


}

Sorry, there's no way to do that in the framework. If it's just one tool, you can still do as I suggested above and rebuild only the assembly you changed. Provided, of course, there are no other plugins that depend on it. If the tool is in an assembly that other plugins depend on, then you would be better to just rebuild CC.

Hope this helps,
-S

 Hi.  I'm new to the ClearCanvas community so I hope this is the right place to ask my questions.  This topic is close to what I'd like to be able to do and might meet the original need.

I see that the ToolSet class loads all the tools for a particular extension using CreateExtensions().  CreateExtensions has an overload that allows the caller to supply a custom ExtensionFilter.  That way, you could selectively disable some existing extension points.  However, the ToolSet does not provide a similar overload.

I think if an overload was added to ToolSet where an ExtentionFilter is passed thru to CreateExtensions, we would be able to avoid loading some tools in preference to others based on the context.  Custom plugin components that create tool sets can use this immediately, but it would also be nice to modify ImageViewerComponent to take in a filter so its set of tools can be specified when the component is created.

I'd love to become more involved in the dev community so I would like to submit the ToolSet changes myself.  What is the process to submit a ticket on a framework refactoring like this?  I've read the "How to Contribute" page, but that says I need to submit patches against tickets.  

Dave

Hi Dave, I see what you mean about the ToolSet - it's API is very limiting in that it only allows you to create a ToolSet by passing in an instance of an ExtensionPoint and a context.  I could see adding a constructor overload for an ExtensionFilter or predicate, but it could be made even more generic by simply adding a constructor that accepts an IEnumerable as well (that way you're not tied to extension points, either).  I haven't looked at this class in a while, but I just noticed that it has a default public constructor, but it does not allow you to modify it's _tools member in any way ... we should probably remove that :)

All that being said, though, filtration of extensions is something we've barely scratched the surface on, as we've mostly managed to get by without it until fairly recently.  There is now a way to enable/disable individual extensions via an Application Setting, but that disables it permanently.  As for runtime filtration, I can't think of many use cases for this because it seems to me that it requires you to know what tools, specifically, you want to use.  In which case, you might just use the IEnumerable constructor rather than instantiating all the tools only to filter a few specific ones out.  Or, you could always just not use the ToolSet class at all, since it's really just a simple helper that creates the tools, sets the context, and disposes all the tools for you.

I've entered a ticket here.  If you would like to submit a patch, that would be great.

Best regards,
Stewart

I agree that letting the ToolSet take a list of tools is the most flexible way to load the tool set.  I've attached a patch that extends the ctors of ToolSet (and removes the not-so-useful default).  Everything in ImageViewer.snl compiles cleanly.  I did not try compiling other solutions, but I did search for the use of the default ctor.  Could not find any code using it.

The old ctor using the all the tools extending an extension point is still there as well as one that lets the caller specify the ExtensionFilter.  Perhaps a plugin expert would be able to use that one.

I also changed ImageViewerComponent slightly so that I can eventually get what I need - a subclass that just has a limited set of tools (for example, if I used it to preview images).  The Start() method calls a protected virtual CreateTools() method that returns the list of tools.  That way, I can override the CreateTools() and slim down the selection (or add very specific tools).  The contruction of the ToolSet still happens in Start so that the private ImageViewerToolContext can be constructed properly.  Perhaps this is not the best way to use the new ToolSet API, but it was a good way to test it.  I would not have seen many tools in the viewer if I messed up.

The Ticket is 4319.

Thanks

Dave

Hi Dave, thanks for the patch! I applied it in revision 9772.

Thanks,
Stewart