Freigeben über

prism v2 – drop 9 (composite application guidance for wpf and silverlight)

  • Artikel

It’s been a while since my last post. Not that the Prism team has been sitting idle though.

Last Friday, we’ve released drop 9 of Prism. As we are approaching the end of the Prism v2 project, there are a lot less API changes, as we are mostly focussing on finishing the docs and resolving bugs. We have also spent some time trying to build different application styles (for example, an outlook style app, or a master-detail style app) on top of our library. The results of this exercise was very useful. Unfortunately, they were nothing more than spikes, so we can’t deliver them as part Prism, but we are thinking of doing a bunch of blog posts or webcasts, that describe how to build different application styles on top of Prism.

You can get drop 9 of Prism here:

https://www.codeplex.com/CompositeWPF/Release/ProjectReleases.aspx?ReleaseId=21912

 

What’s in Prism drop 9

  • New skin for the Stocktrader reference implementation.
    We wanted to show a bit more of the power of the WPF and Silverlight platform in our RI, so we have hired an external design bureau to create a new design. It has taken a bit longer to implement than we had hoped. In this drop, we have some of the basic styling in place. Hopefully, we can get the next styling
  • Desktop only solutions
    Not everybody is interested in developing on both WPF and Silverlight. So that’s why we’ve added ‘WPF’ only solutions. We can’t really add Silverlight only solutions as easily, because the Silverlight projects are linking all the files from the WPF projects.
  • New SingleActiveWindowRegionAdapter in the RI
    We are demonstrating how to create an adapter in the RI, in this case how to create a popup window and use that as a region.
  • Several bugs fixed
    Lots of testing, prioritizing, bugfixing, retesting, etc..
  • Exception stack compression in combination with Unity
    Unity is an awesome DI container, but it doesn’t give really clear exception messages if something goes wrong.

The last weeks of a project are always interesting. There are _so_ many ‘little’ things we would have wanted do do, or add to the library. but what seems like a small dev effort, can quickly add up if you also count the test and doc effort. So, we are constantly keeping a critical eye on our prioritized backlog of tasks. Unfortunately, this means there are a bunch of really interesting stuff we would have loved to tackle, but we can’t.

 

Exception stack compression

While building different application styles on top of Prism, we found an interesting problem.

Suppose the following example: You are creating a simple view. In the Module.Initialize(), you are registering the type of the view against a region that’s displayed in the shell. In the constructor of the view, you have made a small programming error, which causes an exception.

So what’s the result?

A module initialize error. Ok, that makes sense. But what was the exception message inside that? “Exception occurred at target of invocation.”. And inside that? A bunch of ServiceLocator, Unity and Objectbuilder errors. Only somewhere at the bottom of the inner exception list you find the exception that caused the problem.

All these exceptions are perfectly valid from a technical point of view, but not very useful in understanding what’s going wrong.  Ideally, Unity should return a very clear exception message: “Tried to create object X, but could not because of this error message: ‘xyz’”. Unfortunately, Unity does not do this. (After a discussion with the enterprise library team, it turns out that it’s really hard to build this in Unity). I think that developers who are building applications on top of Prism are rarely interested how exactly the DI container builds up it’s objects.  So all the technical inner exceptions are just clutter to them, that’s obscuring what’s really going wrong.

So we have built some logic to try and find the error in the stack trace that actually points developers in the right direction. The goal was to be able to get the following exception message: “An exception occurred while initializing module X, in the constructor of View X, with exception message “XYZ”.

So now in Prism, you can use the extension method exception.GetRootException() to try and find the exception that’s actually causing the problem. It won’t be 100% accurate, but it looks like it really helps in getting to the root of the problem more quickly.

Hopefully you will find this useful to!

Comments