System.AddIn and configuration
Dear people from the CLR Add-In team (or anyone else who has experience with the System.AddIn namespace),
I am using the CLR Add-In architecture for a windows service which needs to import data files on a scheduled basis. The add-ins are created for each different type of data file. But there are some configuration options that need to be set for each add-in. I could probably do this by having the add-in read the exe's app.config for the configuration, but what if i want to have multiple instances of the same add-in loaded with a different configuration? How do i go about this?
Kind regards,
Jeroen Vos
There are two ways you can go about doing this depending on what your needs are.
If you want to have a different configuration setting per add-in then you simply need to store that information in the add-ins config file. When you activate an add-in in it's own AppDomain the system will automatically set the AppDomain's config file to be the one sitting next to the addin assembly [addinassembly].dll.config. The add-in can then query this information directly without having to go through the host.
If you want to give a different configuraiton setting to each instance of an add-in then you are going to need to build a way to pass that information on to the add-in into the object model. The simplest way to do this is to add an "Initialize" method to the add-in view and pass a string representing the config file to the add-in. However, if you pass a string directly then you could potentially face problems in the future if you need to change the format of those config settings. Instead I would recomend that if you need per instance configuration you should build into the object model some direct representation of these settings. This way if you need to change them down the road you'll be able to build adapters for the settings and keep the old add-ins working.
Let us know if you have any other questions.
Thanks,
Jesse
I spoke too fast.
What if different add-ins (with the same contract) have different configuration schemas (as in different configuration properties). In this case a direct representation of the settings would be out of the question would it not?
A string would be a bad option indeed, since there would have to be xml logic in every add-in (since it can't be handled by the view because of the different configuration schemas). Sending over a dictionary of keys and values might be an option but it probably has the same potential versioning problems and it keeps you confined to the key-value pair for settings.
It would be great if you have any more suggestions on how to tackle this.
Regards,
Jeroen
With the different schema's do you want each instance of a specific add-in to have different values or is this something that all instances of the same add-in will share. If the settings are add-in specific and not instance specific then a config file on the add-in itself is still a very good way to go.
If you need to give different add-in's of the same type different schema's how does the host know which schema to give which add-in? Is there some way for the add-in to describe this information to the host so that the host can provide it? Where does the host get the configuration information from to pass the data to the difference schemas? How about giving the add-in some way to request this configuration from a user?
Schemas would be add-in specific, but each instance of an add-in can have different values. For instance, i have the the add-in ImportCsv (of the add-in type Import). The settings for this add-in would consists of a couple of properties identifying the folder from which to read data to import, where to put the back-up of read data. Ofcourse i might want 2 instances of the add-in created, one to import data from say C:\Folder1 and the other to import data from C:\Folder2.
Then there could also be an add-in called ImportDb (also of the add-in type import). This could have settings like, database name, username, password and that kind of stuff. For this add-in i might also like to create two instances, the first to read Database1 and the other to read Database2.
I hope this makes my scenario a bit more clear.
I sounds like you may want to add a UI component to your add-in for modifying the settings, and then have some sort of host callback to send the persisted settings to the host. This would give your host more control over how the settings are persisted.
This would be particularly helpful if you need to, for example, lump all the settings together into a single file, for something like a "project file" that you could open again, and your app would re-load all the same addins and set their respective configurations.
