I am writing an WPF application using PRISM. I am running it through debug from Visual Studio.
When I am creating the Shell, I register an event handler for the Shell's ContentRendered event. This event handler does something unrelated (that I can see is completed on the UI, just filling a ListBox with strings) then unregister the event from the event handler (which I know, in practice, is unnecessary).
If I close the application with the event handler self-unsubscribing, a few threads (that I see on the Visual Studio debug tools) are left alive seemingly forever (>10 min waiting, but the .exe seems to be gone on process explorer), so I have to manually press "Stop debugging" before being able to start the app again.
I can't figure out why this happens. Can someone please explain what is happening?
If I comment out the unsubscription on the code below, the issue is gone:
using Prism.Ioc;
using Prism.Modularity;
using Prism.Unity;
using System.Windows;
using MyTest.Views;
namespace MyTest
{
public partial class App : PrismApplication
{
protected override IModuleCatalog CreateModuleCatalog()
{
return new DirectoryModuleCatalog() { ModulePath = @".\Modules" };
}
protected override Window CreateShell()
{
var Shell = Container.Resolve<MainWindow>();
Shell.ContentRendered += On_Shell_First_Presentation;
return Shell;
}
protected override Window On_Shell_First_Presentation(object sender, EventArgs e)
{
Container.Resolve<IModuleManager>().Run();
// Uncommenting line below gets visual studio stuck
//Container.Resolve<Shell>().ContentRendered -= On_Shell_First_Presentation;
}
}
}
BTW, Am I triggering the loading of the modules the wrong way? If I don't do this, the modules are never loaded, as in, the class that inherits from IModule are constructed but neither functions defined are ever called. I sent OnDemand value on the Module attribute to False. I expected PRISM to trigger it, but I really haven't figured out why it doesn't.
EDIT: Per suggestion on comments, I confirmed that the way it is written actually makes a new Window object to be created but I still do not understand why this would cause this behavior. Fixing the commented line to user a proper reference to the Window instantiated on CreateShell eliminates the issue.