Cross AppDomain Talk

Aug 21, 2008 at 7:35 AM

I have created a WPF Host application and an Add-In, My Add-In contain some WPF UI Element. When I try to activate Add-In in some different appDomain everything work fine but following line of code consume too much time in execution.


HostView.EditorView obj = tok.Activate<HostView.EditorView>(ap);


I want to know that what exectely Activate method does internally? Is there concept of remoting or Serialization behind it, because my application is about cross domain talk.  


Aug 21, 2008 at 11:55 PM
Yes, we use Remoting for cross-domain communication.

The Activate method creates a new app-domain, loads the required assemblies into that app-domain, creates an instance of the add-in and connects it to the host through adapters. These are expensive operations (especially loading assemblies), so it is expected to take some time. But by paying that performance cost, you get isolation benefits. It is up to you to decide the performance/isolation tradeoff, and there are some great resources on to help you make that decision.

Aug 22, 2008 at 12:29 AM
You can also add the following attribute to the Main method of your program:


This, along with adding your contract assemblies to the GAC, should speed things up considerably, especially for WPF scenarios.
Aug 22, 2008 at 12:32 PM
As suggested by mSid, you should definitely apply the LoaderOptimization attribute to your entry point. Do this even if your assemblies aren't in the GAC, otherwise shared assemblies such as WPF assemblies will be loaded for each AppDomain!

Also, be sure to run outside of VS while testing the performance improvements. VS uses its own bootstrap exe with its own entry point that does not have the LoaderOptimization attribute applied to it.

Aug 25, 2008 at 4:24 PM
I have also created a WPF host application and when my add-in (loaded into its own AppDomain) creates a new WPF User Control, I notice a considerable delay.

The main method is included in the generated code for the App.xaml (Build Action: ApplicationDefinition) file. Is there still a way to make use of the LoaderOptimization attribute?

Or would I need to create my own Main method in order to make use of this attribute?
Aug 25, 2008 at 4:42 PM
Does this attribute apply to all assmblies? What impact if any does it have on version resilliance? What are the downsides of using this attribute?
Aug 25, 2008 at 5:32 PM

I don't know of any way to get the auto-generated Application definition to use the attribute. That said, it is very straightforward to write your own entry point.

As for which assemblies this applies to, only assemblies that can be shared safely are shared. The attribute is guaranteed not to affect program behavior. There's some info somewhere on what qualifies as a sharable assembly but I can't find it at the moment.

Sep 5, 2008 at 3:19 AM
Edited Sep 5, 2008 at 3:21 AM
Duplicate - see below
Sep 5, 2008 at 3:19 AM
Edited Sep 5, 2008 at 12:25 PM
@johnhmccauley  the CLR Add-In Team Blog - 2008/02/22  blog explains the importance of the LoaderOptimizationAttribute.

As kentcb indicated there doesn't seem to be a way to get the auto-generated Application definition to use the attribute.  I explain in my blog HERE how to "easily" make the necessary property change to prevent the auto-generated file from being created, allowing you to use the LoadOptimizationAttribute on an App.xml.cs Main method.