Best / standard Silverlight Prism module slowdown method (for testing)

Question

When testing Prism-based Silverlight modular applications locally, XAP modules load too quickly to get the final result. This makes it difficult to see where progress, intros, or other visual states should be displayed.

What is the best (or most standard) method for deliberately slowing down the loading of XAP modules and other content in a local development setup?

I added a random timer delay (via code-based storyboard), but I would prefer something that I can put under the hood (say, Unity bootloader?) To add a significant delay for all module loads and only in debug builds.

Suggestions are welcome *

* Note. I studied the "large file" option and does not work for large projects (and I cannot create XAP with really large files with a memory error). The solution should be code-based and preferably integrated behind the scenes to slow down module loading in the local host environment.

**** Note. To clarify, we are specifically looking for an answer compatible with the Microsoft PRISM template and PRISM / CAL libraries. **

Answer 1

Do not add files to module projects. This adds unnecessary regression testing to your module as you change the layout of the module, expanding the unused portion. Most likely, you will not do this regression testing, and who knows if this will cause a problem. Better to be paranoid.

Instead, come up with a Delay procedure (int milliseconds) that you pass to the callback that materializes the callback that you use to retrieve the remote assembly.

In other words, separate the assembly of assembly resources from the use of assembly resources. Between these two phases arbitrarily random sums of the waiting time are inserted. I also recommend logging the actual time that remote users took to build and use it for future test points so that your user interface designers and QA team have valuable information about how long users wait. This will allow you to cheaply mock up the end-user experience in your QA environment. Just make sure your log contains relevant data, such as the size of the requested assembly.

A few weeks ago, I asked a question about StackOverflow about something related to this , and I had to solve the question that you asked, so I am sure that this is the correct answer, born from experience, not the mind.

Answer 2

You can simply add huge files (like videos) to your module projects. It will take more time to create such projects, but they will also be larger and therefore require more time to download locally. When you move on to production, simply delete the huge files.