Why opening a WPF form from VSTO SE is extremely slow?
I know this is the Orcas form, and maybe you have the answer since the new VSTO is a bit improved from the last one.
So, here is the problem:
If I create a WPF project (EXE) with one form using VS.NET 2005, compile it, and run it with or without VS.NET, the form opens instantly.
If I create a VSTO SE project, and reference the WPF dlls, and then using the code create the same form and show it after the application startup, or with the applications startup (no difference), it takes about 10 seconds to open, and tons of hard drive activities.
Any ideas?
OS: Windows XP SP2, .NET 3.0, VSTO SE, tested on 10 different computers by now.
[1274 byte] By [
G.T.] at [2008-2-19]
Hi,
Got quite the same problem with an Excel addin.
Excel launches but take about 10 sec in order to launch the ThisAddIn _Startup procedure
Nothing to do with the addin code i think, my first instruction (for the tests) is to display a message box ...
Any help please ?
Hello.
This is a known issue with VSTO SE and is only limited to Office 2003. The delay that you're experiencing is due to WPF code getting JIT compiled inside the appdomain hosting the VSTO addin. This happens because VSTO SE hosts the CLR using default settings, causing the CLR to be loaded with STARTUP_LOADER_OPTIMIZATION_SINGLE_DOMAIN flag (see http://msdn2.microsoft.com/en-us/library/99sz37yh.aspx for more info). This results in .NET assemblies (including WPF) to be loaded as domain-specific (as opposed to domain-neutral). Native images of assemblies loaded as domain-specific can only be used the first time the assembly is loaded. Further attempts to load the assembly from different appdomains will result in the code being JIT compiled. Please see the following article which describes this behavior in more details: http://msdn.microsoft.com/msdnmag/issues/06/05/CLRInsideOut.
We are currently investigating ways of mitigating this issue in VSTO SE for Office 2003.
The workaround is to create an additional unmanaged addin to load the CLR with STARTUP_LOADER_OPTIMIZATION_MULTI_DOMAIN_HOST flag (using CorBindToRuntimeEx API). This would ensure that strongly named assemblies are loaded as domain-neutral, and would share their native images across appdomains. Note that this additional addin must be loaded before any VSTO addins. Please see http://msdn2.microsoft.com/en-us/library/99sz37yh.aspx for more information on using CorBindToRuntimeEx.
Please let us know if you have any more questions.
Igor Zinkovsky
Software Design Engineer
Visual Studio Tools for Office
This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm.
