Silverlight Prism Module Not Ready - silverlight

I'm building a Silverlight 4.0 application with Prism (a.k.a. Composite Application Guidance). I have two modules, both defined in my ModuleCatalog.xaml as WhenAvailable. My Application_OnStart instantiates my Bootstrapper and invokes it's Run() method. Well after my application is started and up and running (in fact, the user has to click a button in the UI), I then attempt to load the modules:
foreach (ModuleInfo mi in moduleCatalog.Modules)
...
Type moduleType = Type.GetType(mi.ModuleType); // moduleType ends up null!
Sometimes, moduleType ends up null. I've verified that when I encounter the null, the ModuleInfo's State is LoadingTypes not ReadyForInitialization. I assume this means it's still downloading the separate *.xap files for my modules and bringing their types into the application domain.
So what can I do? I'd happily block if I knew there was some event I could listen to to know they're finally all loaded.

If you are going to use Prism, you should not bypass it and create your modules yourself. That is not the way Prism is supposed to work. Prism does not provide an event for load completion as that is not something you should need to do.
Simple case:
If you define a module catalogue then all those modules will be loaded progressively, so no need to load any manually in that simple case. You can create a start-up module in your root Silverlight app with a few module dependencies and that will be enough to get the first page visible while to rest of the app loads.
More info needed:
I can't tell what you are actually trying to accomplish from the above snippet, so more information would help, but you should be using Unity to resolve interfaces and never Type.GetType() directly. Your generally should not need to resolve a module itself and there are also methods for triggering load-on-demand loading in Prism (don't have them handy at the moment... will update this).
Thanks:
Your have accidentally provided a clue to the answer to another question I asked in Stack Overflow so thanks for that.

Related

How should Prism modules know about each other's views?

I'm very new to modules in Prism and am struggling to understand how to use them properly. I want to have a navigation panel like in the image below, which I stole from Google.
Let's say that I have 3 modules for 3 separate concerns: NavigationModule, HelpModule, and FeedbackModule. If I want to show "Help" when the app first loads, my understanding is that I would do something like the following:
Define Regions for navigation and content in my Shell (main WPF project)
Upon execution, load the navigation view into the navigation Region
Upon initialization of the NavigationModule, load a view from HelpModule into the main content Region
This leaves me with a few questions about what modules should know about each other:
Should the Shell's project have a reference to the NavigationModule in order to load its view?
Should the NavigationModule have a reference to the HelpModule in order to load its view? And a reference to FeedbackModule in order to load its views on demand?
If the answer to these questions is "no," then what's the best way for modules to be aware of each other's views? I could create a shared class library with constants for view names, but it seems a bit troublesome to maintain a bunch of strings that way whereas with references I could use nameof(). I would appreciate any direction. Thanks.
Modules should not "know" each other in the sense of having a project reference from one module to another, because that kind of defeats anything gained from having modules in the first place, that is, to have a modular application (built of components that can be swapped out independent of each other).
Modules should interact through shared interfaces, which are define outside of modules, that is either in the framework or in assemblies that "are" no modules themselves. Depending on your requirements, you should define upfront (and enforce in the build process) which modules there are and which interface-assemblies and which module is allowed to reference which interface-assembly.
So how to show the Help-view when the application loads? Send a message (e.g. via IEventAggregator or any other communication mechanism) when it's time to load the initial view (whatever that may be). The Help-module listens for the message and navigates to the Help-view. Important: the SessionResume-module might also listen for our message. It's the responsibility of whomever choses which modules to deploy to only deploy modules that are compatible with each other.

Using elmahr.elmah in winform application

I have recently shown to my team leader the ElmahR Dashboard and now he wants to implement ExceptionsLog with ElmahR in all of our current projects, including those that are Winform Applications, and after many days of searching I can't find a way to add a Winform Application as "ElmahR source".
Does anyone have a clue?
ErrorPostModule in ElmahR.Elmah does not support Winforms apps because it's been written to be an ELMAH module, so it's tied to an ASP.NET lifecycle and cannot be easily adapted. That said, ErrorPostModule does not do anything so magic and can be easily taken as a guideline to write a small "handler" to be used in a Winforms app. Take a look at its code here, what you should do is:
replace what's in the OnInit method, which simply reads configuration bits and attaches the error handler
when an error occurs, handle it like it's done in the SetError method to post it to the right destination reading the configuration parameters you read before. You would reference ELMAH and create an Error instance from your exception, and then use ErrorJson.EncodeString to encode it
You may want to borrow the W3.cs file to simplify the http form compilation.
At some point I might generalize this work and put it in ElmahR.Elmah, but not sure when I'll be able to do it.
I just forked the elmahr source code to work on this, I want to post errors from console applications, so I'm going to remove the dependency on Elmah and create the "error" objects and send them to the dashboard.
It's a work in progress but can be used as starting point for solving your problem.
https://bitbucket.org/rudygt/elmahr
Update: the fork now include full support to post to ElmahR using a ServiceStack endpoint, using json over http. This remove the dependency over the original Elmah to publish errors to the dashboard. The first example is a C# Console Application

Implementing startup tasks for SL5 OOB application

I am putting together a Silverlight 5 application that will run out-of-browser and has a bit of everything on start-up. Specifically, here are the steps I need to follow:
Check that the app is running out of browser (if not, display a screen instructing the user to install it locally).
Display a "splash screen" (it would be nice if this would play animations while the remaining steps execute).
Configure MEF
Pre-load context information and 'static' data from the server (for example, settings). This data is required before any of the application logic can run.
Dynamically load additional XAP files including an external theme library.
Replace the "splash screen" with the shell which contains a navigation frame.
Navigate to the application's start page.
I also need to support Application Extension Services (IApplicationService, IApplicationLifetimeAware) so any process I implement must respect these services. Most of these services will require MEF to be configured, so they should not execute before MEF has been configured and imports satisfied.
Another consideration is that some imports may be satisfied only after the dynamic XAP files have been pulled in and MEF recomposed.
One of the hurdles I'm running into is the fact that I cannot do step 5 until the previous steps are complete. Loading the XAP files or calling the server for data asynchronously allows the code to proceed. I need a way to "stall" the UI until all of the composition is complete and all required context data has been loaded.
So, I'm looking for recommended approaches that satisfy all of these requirements and am happy to provide more details if that helps get to a working solution.
UPDATE
The best explanation I can give for my difficulty is that I must 'release' the UI thread to display a 'splash screen' but also suspend the normal life cycle of the application while each step executes. I can't (and don't want to) do everything in the Application.Start event handler because application services will have already started.
Plus, releasing the UI thread means I do work in the background and let the original method (Application.Start, for instance) return and the runtime will move forward in the startup process. For example, starting a background process in the Starting method of an application service then returning allows the runtime to raise the Start event on the Application object. But if I need the background process to complete before I can do the next thing, I have to suspend the current thread which blocks the UI.
So I'm not sure how to divide up the work or where to put it (App, application service, bootstrapper, workflow, etc.).
You can use ManualResetEvent class to force the service calls to be Sync (and guarantee the order they complete). You could also use this to synchronize the background thread to the main UI thread.
http://mohundro.com/blog/2006/06/27/a-little-bit-about-manualresetevent/

What is the correct way to solve the ambiguous reference issue in WCF services?

Project Structure
I have a silverlight project SLProj, that references a silverlight class library project called ServiceClients. ServiceClients has two wcf service references, Svc1.svc and Svc2.svc. Both Svc1.svc and Svc2.svc are in two different WCF projects which use the same set of DataContracts which are again in a different class library project called MyDataContracts.dll.
Problem description
Now in my ServiceClients project I get an ambiguous reference issue when I need to use a datacontract class which is present in both the service references. If this were a winforms or webforms project, I could reference the MyDataContracts.dll and reuse the common types. But since, this MyDataContracts.dll was built using a non silverlight class library, it can't be referenced in the silverlight project
Workaround...
I am not sure if this below is the best method to go about taking care of this issue. Can anybody let me know if there is a cleaner way to solve this problem, or is this the best way we have so far?
create a single service reference.
click the 'show all files' button in the solution explorer
drill into the service reference and find Reference.svcmap and open it
find the MetadataSources section
add a second line to include the address to your second service. for example:
MetadataSource Address="http://address1.svc" Protocol="http" SourceId="1"
MetadataSource Address="http://address2.svc" Protocol="http" SourceId="2"
save, close, and update service reference.
Use Automapper
Map the DataContracts with AutoMapper.
You will have to invest some time in understanding AutoMapper and reworking your application. Also AutoMapper adds overhead because all data objects will be mapped. But first you will have a clean solution without hacks and second you gain a decoupled and simple data object layer just for your client. Once done you can forget the mapping but you stay flexible for future changes.
If you never have worked with Automapper it's important to play around with it before starting. Automapper is special and needs some time to familiarise with it.
So there. These are the rough steps:
1. Create a subdirectory and sub-namespace Data and copy the DataContracts. Remove the attributes and properties your client doesn't need because these mapped classes live only in your client. You can also change some types or flatten some complex properties.
2. Create an AutoMapperInit.cs like described at Automapper (read the Getting Started Guide). Use the conflicting references like this:
using ref1 = YourProjectServiceReference1;
using ref2 = YourProjectServiceReference2;
3. Wrap the service client like this:
Example GetExample() {
return AutoMapper.Map<ref1.Example, Example>(ref1.YourService.GetExample());
}
The wrapper also needs the same using directives as in step 2.
4. In this wrapper add a static initializer like this (assuming your wrapper class is called Wrapper):
static Wrapper() {
AutoMapperInit.CreateMaps();
}
5. Omit service references in the client and use using YourClient.Data;, the namespace you created in step 1.
Your client is now decoupled from the service and you don't have conflicts anymore.
Disclaimer: I am not affiliated with AutoMapper. I just used it in a project with a similar problem and am happy with it and wanted to share my experience.
Your workaround is actually quite OK. We've used it in several projects like this with 3 service references. It is actually a workaround for the IDE which for some reason only allows to select one service to create a service reference at a time.
Another thing you could try-out is to multi-target your shared contract to .NET and Silverlight, using the same codebase. Details on how to do such thing is described in http://10rem.net/blog/2009/07/13/sharing-entities-between-wcf-and-silverlight. Might be more work but feel less hacky.

Composite WPF: Global variables?

In a Composite WPF application, what is the best way to store global variables needed by several modules? For example, I am working on an application in which several modules need to get a file name, so they can fetch the data they need from the file.
Is there a best practice for storing information like this in a Composite WPF app? How do I get the information to my modules while still keeping loose couplings? Thanks for your help
David Veeneman
Foresight Systems
Write a service that encapsulates the logic you require and package that service into a module. Then have your other modules use that service to get their job done. Note that the service may expose the file name directly, or may instead choose to expose operations that operate on an underlying file without consumers being aware of said file.
Create an interface who's responsibility it is to return the "selected file name". Unlike most services / dependencies, it won't do a lot of processing - it's just responsible for returning a value. Use dependency injection to provide an implementor of this service to all places that need it.
At the moment this file name might seem truly global, but imagine your app had to transition from SDI to MDI. It's never a good idea to have true singletons in you composite apps.
Thanks for both answers, both of which look very good. I came up with a third approach while out on my morning run, and I think I'm going to try this one:
I load all of the modules in my Composite WPF app at startup and activate only the views that will be shown initially. So, all of my modules, even the ones not shown, are available as soon as startup completes.
When they are initialized, each module that needs the file path will subscribe to a FileOpened composite event in the Prism event aggregator. When a file is opened from the Shell, the Shell View Model will publish a FileOpened composite event. The composite event will carry the file path as its payload.
So, when the FileOpened event is published by the Shell view model, the appropriate callback method in each module will be called by the Prism event aggregator, and the filePath will be passed to each module's view model.

Resources