Modules not working if application compiled in Release mode

Topics: Prism v2 - WPF 4
Mar 18, 2013 at 3:58 PM
I developed an application in VS2010 with multiple modules.

If I run the application within Visual Studio all works fine, both in Debuag and Release mode.
The problem arise when I launch the application directly from the bin directory: in this case if I run the exe in bin\Debug all works fine, while if I run the exe in bin\Release all the views in some modules does not open correctely (the grafic interface is not shown, but I do not get any exception).
The behaviour is really strange since I get this result only for Release and only for some modules.

Does anyone have an idea where to look for the problem?

Thank you
Mar 18, 2013 at 5:43 PM

As far as I know, your application exe should run correctly from the bin folder if you manage to run it without problems in Release Mode in Visual Studio. I tried to reproduce your issue with no success at all. Therefore, it would be helpful if you provide us with more information about your application, like:
  • Which version of Prism do you use?
  • Which version of Visual Studio and .NET Framework are you working with?
  • Which container did you choose (MEF, Unity)?
  • Which method do you use to load Modules (on demand, .config file, from a directory, etc.)?

Federico Martinez
Mar 18, 2013 at 6:46 PM
Hi Federico,
thank you for you reply.
I'm using Prism 4.1 in Visual Studio 2010 Ultimate (version 10.0.40219.1 SP1) with .NET 4.0. As a container I use Unity.
I add all the module to the ModuleCatalog in the bootstrapper with InitializationMode = When Available.
Modules info are stored in a databse table and the module dll are put in the same direcotry as the executables (bin\Debug or bin\Release) and load from there.
I tried to remove one of the faulty module dll and the application give me an exception at start up. With all the modules dll in place the application starts up correctly, but then it seems that the view are not displyed in the regions (I use a tabbed region).
What it is really strange is that this happens only running the application from bin\release and only for certain modules, whose difference from the others I'm not able to cacth.

Massimo Landi
Mar 19, 2013 at 9:20 PM

As far as I know, there are no previous reports from users about not being able to run the application from the Release folder. As a quick test, I tried this with the Modularity QuickStart, which loads modules using several approaches and it worked correctly, so it doesn't seem to be a bug in Prism.

Based on your description, it seems that your application looks for the module files correctly (that is why it throws an exception when you remove a module dll), so there might a problem during the initialization of the modules. As a starting approach, you could temporally modify the modules to log or show an message when they finish their initialization logic (for example, at the end of the Initialize method) to check that the modules are being initialized. Also, you can subscribe to the LoadModuleCompleted event to check if a module has been correctly loaded or not:
Another point that might be worth checking are the Regions to ensure if the views are being correctly injected or not.

On a different note, you mentioned that you are obtaining the ModuleInfo of each module from a database. Are you using a custom ModuleCatalog / ModuleTypeLoader to load the modules using the database directly or are you using the default implementations and simply passing the ModuleInfos obtained from the database? If you are using a custom implementation your problem might be related to it.


Damian Cherubini
Mar 21, 2013 at 11:22 AM
Hi Damian,
thank you for your reply.
I do not receive any excpetion in all the process of navigaion toward the view and both inserting try-catch in nitialization logic (Initialize method) and using LoadModuleCompleted gave no result.
I'm using databse just to store information that I pass to ModuleInfos and I use standard methods.
One thing I have noted is that if, in bin\Release I replace the dll of the faulty module with the dll compiled in bin\Debug all works fine!
Could it be possible that, for some reason I ignore, the way I navigate to the view:
regionManager.Regions[RegionNames.ContentRegion].RequestNavigate(selectedCommand.ViewTypeFullName, np)
is not able to locate the view when compiled in release mode?
NOTE: the np parameter in RequestNavigate is used with an extension that allow me to pass parameters when navigating.

Massimo Landi
Mar 21, 2013 at 8:23 PM
Edited Mar 21, 2013 at 8:30 PM
Hi Massimo,

Based on your findings, I believe we could say that your application is correctly loading and initializing the modules and this problem might not be related with them.

The next "suspect" we could analyze is the UI Composition logic of the application: if the modules are being loading correctly but the views are not being shown, there might be a problem when injecting the views in the regions. Now that you mention that you are using Navigation, I believe that it's important to note that Prism's Navigation API automatically swallows any exceptions that might arise during the navigation process. As a result, if an exception is thrown in a RequestNavigate the view is not injected in the region, but the application doesn't crash. In order to find if an exception is being thrown during a Navigation Request, you can either subscribe to the NavigationFailed event of the RegionNavigationService or pass a callback to the RequestNavigate method. You can find more information about this in the following chapter of the Prism documentation:
As to why this is happening when building in Release and not in Debug , my guest is that it might be related to a timing issue. Based on my understanding, when building in Release Mode, the compiler optimizes the code in order to improve the performance and therefore, it might be possible that a hidden timing issue in the application could appear as result of the performance improvement. An example of a timing issue, if the ContentRegion is not created before the Navigation Request is invoked, it will fail.

If this does not help in finding the cause of the problem, it could be useful if you could provide us with a repro-sample application that we could analyze in deep so that we can help you further with this.

Finally, as a quick test, try to build your application in a different computer just to check if this is not something generated by your Visual Studio installation.

I hope this helps,

Damian Cherubini