Plug-ins

R

rbulph

Junior Contributor
Joined
Feb 17, 2003
Messages
397
Given a set of objects implementing a particular interface, what's the best way to store a user's choice of object from that set between sessions?
 
By "sessions" do you mean you fire up your application, select and run plug-ins, and then shut down your application is 1 session?

How about an XML file?
Code: 
<plugins>
   <plugin selected="true">Fully.Qualified.NameOfPlugin</plugin>
   <plugin selected="false">Fully.Qualified.NameOfOtherPlugin</plugin>
   ...
</plugins>

You could also simply output the names of selected plug-ins to a text file. One per line would be easy to read.
 
mskeel said:
By "sessions" do you mean you fire up your application, select and run plug-ins, and then shut down your application is 1 session?

How about an XML file?
Code: 
<plugins>
   <plugin selected="true">Fully.Qualified.NameOfPlugin</plugin>
   <plugin selected="false">Fully.Qualified.NameOfOtherPlugin</plugin>
   ...
</plugins>

You could also simply output the names of selected plug-ins to a text file. One per line would be easy to read.
Click to expand...
Yes, I'm thinking about how to store the choice between uses of the application. It's actually a choice of a particular object within a plug-in that I want to store.

My concern is that a plug-in could be superseded by a different version. The names of the plug-in and of the object might change, but the CLSID (if .net has these) might be more durable. So wouldn't that be better to store than the fully qualified name, and if so, how do I get hold of it?
 
.Net objects use what is called a strong name to identify themselves not a guid. A strong name is a combination of the assembly name, culture, version and public key used as part of the signing process.

If you are not overly concerned about versioning then you can just load an assembly by filename alone, if versioning is important then the strong name can be used to ensure the correct / later versions are loaded.

You could either maintain the class names between versions to prevent failures or possibly use some other structure to contain this information i.e. alongside the .dll also have a .xml file that contains information regarding the .dll to use, the class name as a minimum but you could also specify additional information like display names (if the UI needs to display things), enabled / disabled state etc.
 
Last edited:
The details are a little sparse in the documentation link I posted so I could have missed some details, but the example looked like it would do the trick...
MSDN said:
The following code sample demonstrates how to attach and read a Guid object as an attribute on a user-defined class or interface.
Click to expand...
 
I'm wondering if the simplest way to deal with this might be to trust serialization to do it for me. If I create an instance of the object and serialize it, I can then get it back with serialization. The serialization engine (if there is such a thing) will surely deal with any versioning issues for me.
 
Is it possible that the deserialization will fail if the assembly is not loaded? Or is there an important detail that I am missing?
 
rbulph said:
I'm wondering if the simplest way to deal with this might be to trust serialization to do it for me. If I create an instance of the object and serialize it, I can then get it back with serialization. The serialization engine (if there is such a thing) will surely deal with any versioning issues for me.
Click to expand...

So far I've only used the XMLSerializer in .NET, but it needs to be initialized with the object(s) (actually the type of the object(s)) you want to serialize/deserialize. So I dont think you can leave it up to the serializer to fully instantiate the object, it needs the information about what to expect in order to work.
 
marble_eater said:
Is it possible that the deserialization will fail if the assembly is not loaded? Or is there an important detail that I am missing?
Click to expand...
Probably, but then I won't be able to create the object that's needed, so as long as I trap the error, it's not really a problem.
 
Wile said:
So far I've only used the XMLSerializer in .NET, but it needs to be initialized with the object(s) (actually the type of the object(s)) you want to serialize/deserialize. So I dont think you can leave it up to the serializer to fully instantiate the object, it needs the information about what to expect in order to work.
Click to expand...
I will intialise it with a reference to an object declared as the type of interface. Do you know as a fact that it won't then create the right type of implementing object, or are you just speculating?
 
Back
Top