Need to Debug through SilverLight PRISM but can't

Topics: Prism v4 - Silverlight 4
Feb 17, 2012 at 3:40 PM
Edited Feb 17, 2012 at 4:21 PM

I am attempting to zero in on an issue I am certain is mine, but can't figure it out.  The issue happens when I am removing items that are in regions.  Its a complex scenario so rather than get into the steps all I know is that prior to my issue I can execute this

      myRegionManager.Regions.ContainsRegionWithName("DockingControl_Home_Center_DockViewsRegion" );

 ... which I use as my test. 

As a test I sprinkle this line throughout my code until it throws an exception.   The exception is an UpdateRegion Exception and I can see that it likely surfaces from PRISM Region manager's ContainsRegionWithName method within the call to UpdateRegions ... As I said, it is more than likely something that I am doing to cause this so I thought, why not add the PRISM project to my SilverLight project and attempt to debug through PRISM to trace through the issue. As you will read, I can't seem to add the necessary PRISM source projects to my solution that would allow me to debug through this scenario. 

To further understand my root-issue, the exception I am receiving relates to adding a Region, however at this point in my code, I am only removing a view from an existing region.  The test I added was because later on in my logic, I remove that same region and I was getting this same PRISM exception, again elluding to an error adding a region, when in fact I was removing a region.  I looked at the PRISM source and notice that both Remove() and ContainsRegionWithName both call UpdateRegions() which is why I decided to use the line "ContainsRegionWithName ..." as a test to see if I could narrow that scope down.  I am not exactly sure what is causing my exception and so I am wanting to debug through PRISM to see.

The actual PRISM exception message is

 Region with the given name is already registered:

Which seems to orginate from RegionManager.Add. Just prior to removing the view, I was able to excute my test line (i.e. call into RegionManager and test for whether or not ContainsRegionWithName returns true, which it always does, as that region is there). I see it under debug watch. Also in the past when I have a situation such as this, I normally see an exception within Debug Watch but I do not see that here, all appears to be very normal. Again, I am certain this me but find it very odd that prior to removing a view, that I do not receive any exception through this test, but only after a remove the view do I get it. 

Further, why is UpdateRegions() calling through RegionManager.Add as a result of me sucessfully removing a view from a known region? 

This seems a bit weird which is why I am keen to debug through the PRISM libraries to see what is causing the call to Add..

Unfortunately when I add the PRISM.SilverLight project to my solution I can sucessfully compile it and reference through my existing projects however when I attempt to compile my SilverLight applications I receive the following compile time error.

'Microsoft.Practices.Prism.Bootstrapper' is defined in an assembly that is not referenced

Many times in the past year I wanted to do the same, but always I hit this same issue, so I end up spending many hours/days debuging around PRISM when I know I'd get quickly to my error if I could debug through the PRISM assemblies.

Is there any guidance out there that illustrates what bits to include in my solution to allow me to debug the PRISM libraries?

I thank you in advance.

Cheers 

Developer
Feb 17, 2012 at 4:57 PM
Edited Feb 17, 2012 at 4:58 PM

Hi,

As mentioned in this thread, the error you are getting might be caused because you're adding some references to compiled assemblies, and some to the projects. in order to avoid these errors, you could try removing all the references in your target solution, and then adding the references to the projects from the Prism Library (not the compiled DLLs).

Additionally, you can find more information in the Prism documentation at MSDN:

I hope you find this handy,

Agustin Adami
http://blogs.southworks.net/aadami


Feb 17, 2012 at 5:57 PM

Thank you Agustin however I am still unable to debug through the PRISM libraries although I no longer get the error message

'Microsoft.Practices.Prism.Bootstrapper' is defined in an assembly that is not referenced

Note: I followed the instructions which state to remove the build option from Configuration Manager for all PRISM projects I include (which is the Interactivity, MEF and Silverlight PRISM projects).  I then changed the reference of each of my projects within my solution to point to these projects as reference and when I attempted to compile my project(s) I received an error stating that the compilier could not find the assemblies for PRISM. So knowning that I can't compile the 3 included PRISM projects I instead copied over the contents of the PRISM\Bin folder into each of the debug\bin folders for each PRISM library.  At that point, my compile error went away however even though the applicaiton boots up, it is not allowing me to step through and into the PRISM code.

I was thinking, that the PRISM binaries that I copied over from the PRISM Bin folder to each of the PRISM debug\bin folders would most likely be release versions (even though they contained PDB files) so how or where does one get a set of Debug assemblies that are strongly named?  I suspect that is my current issue.

Any thoughts on what I can try next? 

Developer
Feb 22, 2012 at 8:03 PM

Hi,

Based on my understanding, as you copied the compiled Prism assemblies in the debug\bin folder of each project, your application seems to be using those assemblies instead of the Prism projects.

As far as I know, you should be able to replace the compiled Prism assemblies with their corresponding projects without problems. It would be helpful if you could provide us with more information regarding the error you are experiencing when trying to compile the Prism projects (for example, the classes or assemblies that are missing, the references of each project, etc).

Also, as a possible approach, you could try to replace the Prism assemblies with their corresponding projects in one of the several Quickstarts provided with Prism. If, after doing so, you cannot compile the Prism projects in the Quickstart, it would be helpful if you could provide us with the modified Quickstart in order to help you understanding what is preventing the Prism projects from being compiled.

Regards,

Damian Cherubini
http://blogs.southworks.net/dcherubini