DevForce 2009: Dynamic loading of model assemblies (Prism)

Dynamic loading of model assemblies (Prism)

Printed From: IdeaBlade
Category: DevForce
Forum Name: DevForce 2009
Forum Discription: For .NET 3.5
URL: http://www.ideablade.com/forum/forum_posts.asp?TID=1699
Printed Date: 20-Sep-2025 at 1:51pm

Topic: Dynamic loading of model assemblies (Prism)

Posted By: ahopper
Subject: Dynamic loading of model assemblies (Prism)
Date Posted: 26-Mar-2010 at 6:54am

Hi, folks-

We are building a Prism-based application that dynamically loads prism modules based upon UI events (such as Silverlight navigation). Some of these modules include IdeaBlade functionality, so we were intending to have them register their data models by adding them to the IdeaBladeConfig.ProbeAssemblyNames collection when the module is loaded and initialized. Unfortunately, it appears that there is some point at which IdeaBlade performs a definitive scan of that list of ProbeAssemblyNames. If we have the main Prism host download and register the model assembly on application startup all works properly, but if we download and register the model assembly on-demand, it fails with serialization exceptions stating it cannot locate the type information such as the below:

There was an error while trying to serialize parameter http://ideablade.com/EntityModel:entityQuerySurrogate - http://ideablade.com/EntityModel:entityQuerySurrogate . The InnerException message was 'Type 'IdeaBlade.EntityModel.EntityQueryProxy`1[[<<our type/assembly>>]]' with data contract name 'EntityQueryProxyOfEventBaseiy2S35Ri:http://ideablade.com/EntityModel' is not expected. Add any types not known statically to the list of known types - for example, by using the KnownTypeAttribute attribute or by adding them to the list of known types passed to DataContractSerializer.'. Please see InnerException for more details.

Is there a way to force a refresh of the known types after updating the ProbeAssemblyNames collection rather than requiring us to load & register all model assemblies at startup? The list could get quite long, which can make the application take longer to start.

-Andy Hopper

Replies:

Posted By: ting
Date Posted: 29-Mar-2010 at 3:31pm

Hi Andy,

We have a new discovery architecture using MEF in DevForce 2010 that should accomodate you better (and we can talk about further enhancements if you need). For DevForce 2009, if you have a specific type that needs to be probed (e.g. verifiers, login managers, id generators) we may be able to show you a mechanism that can get it loaded dynamically.

Posted By: kimj
Date Posted: 29-Mar-2010 at 7:06pm

Known type discovery does occur early, as DevForce looks for known types when initializing WCF communications on both client and server. Unfortunately I don't think DevForce 2010 will help in this regard, since any type which will later need to be serialized/deserialized between tiers needs to be known at the time communications are initialized. DF2010 will supply a slightly easier means of feeding known types into DevForce, but the need for this information at service/proxy startup is the same.

The only thing I can think of is to start communications as late as possible. On the client this means creating a disconnected EntityManager and calling ConnectAsync only after your model assemblies are loaded and registered. This might carry through to the server too, since it's the EntityServer which needs known type information, and it's the EntityServer service which is started on the first client Connect.

Posted By: ahopper
Date Posted: 30-Mar-2010 at 3:35pm

Hm. Is there a way to force a re-initialization? We'd prefer not to download model assemblies until the Prism module that refers to them is on-demand downloaded.

Posted By: kimj
Date Posted: 30-Mar-2010 at 7:52pm

There isn't currently a way to force this re-initialization, although it will occur automatically after a communications failure. I still think that if you either create the EntityManager late, after the on-demand load, or create the EntityManager in a disconnected state --

var em = new DomainModelEntityManager(false)

and then connect once the model has loaded and the ProbeAssemblyNames updated it should work. Can you provide more info on the order in which everything's happening?

Posted By: ahopper
Date Posted: 13-Apr-2010 at 12:31pm

Sorry it took me so long to reply.

We have a modular application that can dynamically load components (it's a Prism application that uses Navigation callbacks to load modules on-demand so we have shorter startup times). Rather than have one giant model assembly for everything, each module has its own domain model, and this model is registered during the module initialization process (we just add it to the list of probe assemblies). Ideally, we'd like to have it "just work" (i.e., adding a model to probeAssemblies causes the internal list to refresh), but failing that we were hoping for a way to force that refresh.

Right now, we've created a workaround where we separated the modules into a "domain model" module and a "functional" module and placed the domain model modules dependencies in the intial module catalog of the Prism app which therefore force-loads all of the domain model assemblies at startup. However, this causes startup overhead (larger XAP file, etc.) we'd like to avoid.