In this post I assume you have read my first post on this subject. You can find the first post here. In the first part of this blog post, I explained briefly what MEF is and I showed how you can extend MEF with a custom ExportProvider, so that instead of configuring your exports with attributes, you could configure your exports with a XML file. The advantage of using a XML file over using attributes is that the application doesn’t need to be recompiled when your exports change. But when you change your XML file, the application may need to restart, or you could poll the file for any changes. In this post I’m going to show how you can make use of MEF’s recomposition features to recomposition on the fly when the content of the configuration XML file is changed.
Well, what is MEF recomposition? Take a look the the following code snippet:
If you’ve read my first blog post, all of this should be familiar, except the “AllowRecomposition=true” and the “AllowDefault=true”. The latter just means that when MEF can not find a suitable export to match this import, it will inject null instead of throwing an exception. I’ll come back the “AllowRecomposition” part in a minute. First take a look at the following code snippet:
This should also be pretty familiar. Let’s go back to the “AllowRecomposition=true” part. When MEF is asked to satisfy all the imports of the Printer object on line 5, it records that the imports of the Printer object has been satisfied and MEF keeps a reference to the Printer object around thanks to the “AllowRecomposition=true” option specified on the Import attribute. When the exports change, MEF can now automatically satisfy the imports of the printer object again using the new exports. This happens automatically and you don’t have to call ComposeParts() again. When the configuration file is changed when hitting line 8 and after pressing a key, the second Print method should display something different based on how the configuration file was changed. Let’s take a look at how the LinqToXmlExportProvider class was enhanced to make this all possible.
Most of this class was covered in my first blog post, so I’ll only cover the additions to this class:
- Line 5: I need to keep an eye on the XML configuration file and get notified when it changes. I use the FileSystemWatcher class for this.
- Lines 10-13: This is the instantiation and configuring of the FileSystemWatcher. I’m not interested in all the events, only when the content of the file changes.
- Lines 17-50: This is the method where it all happens. This method is responsible for handle the event when the configuration file changes and it needs to notify MEF of the changed exports. Let’s take a look at it in more detail:
- Line 19: First thing to do when the file changes is to parse the file again into a new Dictionary of contractnames with implementing classes.
- Lines 22-26: I need to find out which contracts were removed (properties of classes with imports of these contracts need to be set to null) and I need to find out which contracts were added, so that imports that previously were injected with null can now be satisfied with a value. I use the LINQ Except() method to accomplish this. I immediately create ExportDefinitions out of these contracts using the CreateExportDefinition() method. We’re skipping a few lines to take a look at this method next.
- Lines 53-58: The CreateExportDefinition() method, it takes a contractname and creates an ExportDefinition for it. An ExportDefinition contains a contractname and metadata. It took me a while to figure it out, but for the recomposition to work the metadata has to have at least one key / value pair. The key is the constant string defined in the “CompositionConstants.ExportTypeIdentityMetadataName” variable and the value is simply the contractname. It’s of great importance that this key / value pair is present in the metadata or else you can spend your whole day debugging wondering why nothing is happening .
- Lines 28-31: I also need to find the contractnames that were present in both old exports and the new exports. I do this by joining the old mappings with the new mappings (LINQ’s standard join is an inner join).
- Lines 31-41: Iterating over the joined mappings to find out if the implementing class belonging to the contractname has changed. If so, it’s both added to the removed and the added collections.
- Lines 44-48: To let MEF know that the Exports have changed and it needs to recomposition, I need to fire the ExportsChanging event of the ExportProvider. I can use the inherited OnExportsChanging method for this on line 46. This method accepts an ExportChangeEventArgs that needs two IEnumerables, one of the removed exports and one of the added exports. You can see that the call to the OnExportsChanging() method is wrapped in an AtomicComposition in a using statement. You can compare the AtomicComposition to the TransactionScope class. Recompositioning happens in a transaction and can be rolled back using the AtomicComposition object. When everything went ok, you call the Complete() method.
- Line 49: After everything went ok you can fire the ExportsChanged event. This isn’t really needed for recomposition but maybe your application wants to notify the user that the functionality of your application has changed. To make this possible you need to fire the ExportsChanged event by using the inherited OnExportsChanged method, supplying the same arguments as to the OnExportsChanging() method. Since this event does nothing for recomposition, it doesn’t need a transaction and null is supplied for the AtomicComposition.
Well, that’s it! This is all that is needed to let your custom ExportProvider know to MEF that recomposition is needed. Just imagine the possibilities, automatically recompositioning when you receive an email or a message from a message queue, they are endless. You can find a full working solution of the code above, here.