Challenges using plugin architecture

Dec 10, 2012 at 11:19 PM

I have my own GIS application with UI that has been working will with the DS Map control and Legend. I wanted to add some features found in the plugins to my application but did not want to change my application into a plugin and let DS manage the UI. In other words, I just want to add add-in support to my existing application.

I followed the instructions and examples regarding making IHeaderControl public (as well as IStatusControl and IDockManager) and continued to get error messages that no controls of this type were found. I followed the example in the DemoMap code (which is really simple) carefully but it just wouldn't work.

I then traced through statement by statement comparing my activation with DemoMaps and found the problem in AppManager.cs EnsureRequiredImportsAreAvailable. That calls GetRequiredImport and it turns out that it is looking at the assembly of the .EXE for those darn methods. But I had mine set up differently:

GIS.EXE (stub project that basically calls my class library routines)

GIS.DLL (contains my forms, methods, etc. This is where I had exposed my IHeaderControl, etc.)

The reason why I do this is because sometimes I want to show my GIS application from the start menu and other times call it from another application or library. When I moved my "SimpleHeader" etc. to the assembly associated with the EXE, it started working. 

Next my task was to trap all occurances of the header control trying to load extensions and redirect them to adding to my preferred menu locations. I also would have to trap my menu picks and translate those into calls through the IHeaderControl. What a pain!

But wait...

It later started complaining about *two* instances of IHeaderControl, etc., and I looked and looked and could not find a second one. It turns out that at some point I had no header and it automatically downloaded the libraries using NuGet. Where are those stored? In %appdata$\appname\extensions\packages\etc.! So DS is loading plugins from Application Extensions, Plugins, and also that NuGet packages folder.

I deleted those MenuBar, DockManager, and Ribbon assemblies in the packages folder, and thats is screwed up because I think the NuGet manifest thinks those are still there.

I appreciate the slick way that DS is trying to allow you to very simply build a fully functioning application, but it has been dumbed down so much that it seems to just take control. If I could, I'd just bypass the whole extensions approach and directly reference the plugins I want to include in my application. I know that isn't flexible, but I really only want some specific functionality anyway (e.g., Web Basemaps). Unfortunately, because the front end for that extension is configured as a plugin, there are no public methods or alternative interface what would allow me to utilize it.

My options are to copy the Web Basemap plugin code and create my own version that I can reference and make calls to, but then I lose the ability to utilize other plugins. I also need the GDAL plugin but I don't think that requires the IHeaderControl setup.

My other option is to convert all my code into a plugin. That is a lot of work and I really wouldn't end up with what I want in the UI.

In summary, the effort that the team made to simplify the building of a full featured application kind of gets in the way of using all that wonderful code unless you are willing to have your application take a back seat to MW6.

Nevertheless, I don't want to seem ungrateful! Thanks everyone for listening.

Dec 20, 2012 at 5:29 PM


Try to check this answer

  I hope it will help you using the GDAL in your project without loading it as a plugin, i didn't try it yet but (atv) send it to me as a reply for my question

And for loading other plugins i had the same problem but (ambiente, oscarafone77) help me with this code to load the [Measure] Plugin you can find it here


Hope you find them useful