Loading addins too slow

Feb 4, 2008 at 12:06 AM
Hi there,
I have just started using the Addins you have developed, and I have to admit they are super cool. I am having one problem with the addins and thats the slowness issue. I have tried everything to make the Addin load faster but I have reached a dead end. There is a delay of about 6 seconds. At first I thought it was the Addin content that was too much to load, but even after I made a blank addin with one button, I still have the same problem.

The time is mostly being spent when I call addInToken.Activate . I have tried setting AddInToken.EnableDirectConnect = true; before working with the AddIns, but no performance was gained. Please advise on how I can resolve this slowness.

The code to load AddIn is as follows:

String appPath = Environment.CurrentDirectory;
AddInToken.EnableDirectConnect = true;
Collection<AddInToken> addInTokens;
AddInToken addInToken;

addInTokens = AddInStore.FindAddIn(typeof(VOGAAddIn), appPath, part.Path, part.Assembly);

addInToken = addInTokens0;
this.vogaAddIn = addInToken.Activate<VOGAAddIn>(AddInSecurityLevel.FullTrust);
Feb 4, 2008 at 2:54 PM
According to the documentation EnableDirectConnect only works if thee addin is in the same appdomain as the host. instead of: this.vogaAddIn = addInToken.Activate<VOGAAddIn>(AddInSecurityLevel.FullTrust);


this.vogaAddIn = addInToken.Activate<VOGAAddIn>(AppDomain.CurrentDomain);
Feb 4, 2008 at 5:04 PM
Edited Feb 4, 2008 at 5:05 PM
There is actually a way to dramatically reduce the add-in startup time of WPF based add-ins and still take advantage of the AppDomain isolation. The perf hit you're seeing is that we are re-initializing WPF in both AppDomains, instead you need to configure your host so that they get shared across domains.

To do this you need to apply the following attribute to the main method of your application:
This will indicate to the CLR that you want to share WPF assemblies (and other shareable assemblies) across AppDomain boundaries.

You should note that this only will take effect when the attribute is placed on the "main" method of the EXE that starts the process. This means that, by default, you won't see these improvements when you debug from VS (F5) because VS has it's own vshost process that it uses. If you need better performance while debugging from VS you can turn off this VS host process by going into the project properties of your host project, moving to the debug tab, and un-checking "Enable the Visual Studio hosting process" checkbox at the bottom of that tab.

For an sample that demonstrates all of the above you can see the WPF Calculator sample. You can also take a quick look at the relevent source file in the project Application.cs

Let me know if you have any other questions.


Feb 4, 2008 at 10:11 PM
Thank you all for your feedback. LoaderOptimization has helped speed loading time of the Add Ins dramatically.
Jan 23, 2009 at 5:53 PM
Hey guys, I appreciate all the valuable info i've found on this site.  But, as the story goes... just when I start to think I really know what I'm doing I get stuck in something and I wonder if I really dare to call myself a developer!

I'm using VSTA to extend business objects (all in DLL form) that are customized via a Windows Forms app and then used by a Web application at run-time.  We load LOTS of addins that have 20-200 classes with mlutiple events in each and each event makes 10-100 calls to read/write properties on the host object.  So, when I learned about this MultiDomainHost thing It's very encouraging.  The problem is I don't know how to do the things you guys are talking about with the attributes.  Let me explain...

I have a windows forms app created in 2008 and I can't find a Sub Main() anywhere.  From what I've read it's "hiding" inside some cool new features and even after turning them off I can't get the Sub Main to show itself.  Any ideas?

Also, when a Web Service is loading up my DLL's how to I tell the web service to do teh MultiDomainHost thing?  I can't modify the source of IIS, so what's the trick.

Thanks in advance...