Dynamically loaded assemblies through auto-update and the OpenNETCF.IoC Framework

Sep 22, 2009 at 2:20 PM


Firstly I really like the framework based on what I have seen with the sample app :)

My app needs to have an auto-update feature (which I will be creating through the Mobile App Blocks from P&P) which will retrieve not only updates to the current assemblies that make up the system but also new ones that will support needed hardware functionality such as RFID, Bar code and GPS.

The retrieved assemblies may also be for new user features that each require their own UI (which must be dynamically created as needed) as well as non-UI process or agent type of features.

Does the framework cater for this? (Basically I need to get past using the ProfileCatalog.xml for loading assemblies as this is too static and I will not know the assemblies at design time)

If so, any advice on how best to achieve what I need?

Regarding the DAL, you seem to centralise all data access for all modules in one project. This obviously limits my ability to provide completely independent modules which contains their own views, presents and DAL code. Any recommendations on how to use the framework to achieve this?

How does this framework compare to the current Mobile App Blocks http://mobile.codeplex.com/ and the Container Model which is being pushed by MS P&P?


Oct 7, 2009 at 7:26 PM

The current framework certainly can do a plug-in type architecture.  I'd love to put together a sample for this, though I can't make any promises on delivery dates since I'm pretty swamped with work right now.  It would work the same as it would in the SCSF/CAB though, so you might look for tutorials there. Essentially you would not use the ProfileCatalog.xml file, but instead insert your own IModuleInfoStore.  That file could use reflection to find your plug-ins, or any other form of config, then return the appropriate store XML.

As far as the DAL goes, my belief is that the DAL module should handle all data access.  If a plug-in needs to extend the DAL's capabilities, you should create an interface for teh data accessor, create an implementation in your plug in, and then pass that instace into the DAL so it can do the work with it.  Spreading actual access to the data store across multiple modules makes for a headache when trying to extend or maintain a project.