none
Word and Excel 2010 slow to quit upon opening a WPF window in add-in RRS feed

  • Question

  • I am experiencing strange behavior in my VSTO add-ins. I have add-ins for Word, Excel, Power Point and Outlook built in Visual Studio 2010 as Office 2007 add-ins. They all put a button in the existing ribbon. Upon a button click a standard file dialog is immediately shown followed by a WPF window for user input. When I quit Word or Excel after WPF window was opened at least once, there is a significant delay of 5-10 seconds before the app quits. The same behavior under the same circumstances is not observed in Power Point or Outlook.

    To test this theory I have commented out showing of WPF window and Word and Excel quit immediately without a delay. So I am blaming this on WPF. Are there any considerations for WPF usage from a library such as VSTO add-in? Is there any special initialization or shutdown that needs to be performed? Is what I am trying to do supported at all?

    Wednesday, September 15, 2010 8:50 AM

Answers

  • RE: "Are you saying that since Office 2007 add-ins are built against Office 2007 PIAs, they are not really compatible with Office 2010?"? Just the opposite: Office 2007 add-ins are compatible at run time (on end user computers) with Office 2007 and Office 2010. This is because Office 2010 includes "binding redirect" assemblies that redirect calls by an Office 2007 add-in into the corresponding Office 2010 PIA (see "Binding Redirect Assemblies" in http://msdn.microsoft.com/en-us/library/15s06t57.aspx).

    The point of my last paragraph was that in order to build an Office 2007 add-in, you should do so on a development computer with Office 2007 installed (not Office 2010). The fact that Visual Studio installed private copies of the 2007/2010 PIAs for development purposes allows you to get away with building an Office 2007 add-in on a development computer where you have Office 2010 installed; however, you will not be able to debug/run the project in this scenario.

    The following article provides more details about which types of projects can be run in different versions of Office: http://msdn.microsoft.com/en-us/library/bb772080.aspx.

    In short, to develop a single add-in that targets both Office 2007 and Office 2010 in Visual Studio 2010, you have two main options:

    • Target the .NET Framework 3.5, and develop an add-in that targets Office 2007. This add-in will work on end user computers with Office 2007 or Office 2010 installed, but it will be restricted to features that are available in Office 2007.
    • Target the .NET Framework 4, and develop an add-in that targets Office 2010 or Office 2007. By default when you target the .NET Framework 4, all PIA types used in your add-in are embedded in your add-in assembly, which effectively "decouples" your add-in from a specific version of the PIA at run time. If your project targets Office 2010 and you want to use Office 2010-specific features when your add-in is loaded in Office 2010 but still have your add-in work fine in Office 2007, you can use a strategy like the one outlined here

     


    This posting is provided "AS IS" with no warranties, and confers no rights.
    • Marked as answer by Bessie Zhao Thursday, September 23, 2010 10:09 AM
    Monday, September 20, 2010 9:00 PM
    Answerer
  • Here is my final conclusion. Considering my exotic system and requirements I seem to have found a winning combination. All it takes for my WPF add-in to function normally without any RCW related or other exceptions is to merely copy the <ProjectProperties> section of the .csproj file from an Office 2007 compatible add-in back to my project (which was messed up because of an unwanted upgrade).

    I also instructed Visual Studio not to upgrade my Office projects by changing VS Options as previously advised.

    After merely rebuilding the solution, I have no issues from before. Suddenly all is well.

    What is the big change introduced by different <ProjectProperties> sections? How does this affect the add-in? The only obvious change I am currently experiencing is the fact that I can no longer run or debug my add-ins unless I explicitly attach to an Office process. I used to be able to F5 or Ctrl+F5.

    • Marked as answer by Bessie Zhao Thursday, September 23, 2010 10:10 AM
    Tuesday, September 21, 2010 11:25 AM

All replies

  • Hello,

    Thanks for posting. When you quit Word or Excel, have this WPF window been closed? To reproduce this issue in my side, would you mind sharing a simple project (Word Add-in or Excel Add-in)? So that I could use it in my side to reproduce this issue in my side. Also have you tried to use a Window Form instead of WPF window? How about the result?

    As far as I see, when we open a WPF window, it will create a new thread for it. So the message is separate. Also here is a thread for this topic which could help you: http://social.msdn.microsoft.com/Forums/en-US/vsto/thread/20b6b2d9-2870-4f8d-a02f-f600c25008b8/.

    If this post does not help you, or you have any concerns/comments, just feel free to follow up. Have a nice day.

    Best regards,
    Bessie Zhao - MSFT
    MSDN Subscriber Support in Forum
    If you have any feedback of our support, please contact msdnmg@microsoft.com.


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Thursday, September 16, 2010 3:16 AM
  • Thanks for helping out. I will try to prepare a sample soon.

    In the meantime, I have tried the new thread approach as suggested in the other post, but this failed with an error of its own: "COM object that has been separated from its underlying RCW cannot be used.". I have modified the sample so that Application is not used but a ShowDialog() is invoked on the Window instead. When Application.Run() is used, the Window is apparently opened modeless. This is not desirable.

    Thursday, September 16, 2010 10:52 AM
  • I have revamped everything to try another approach and now I am getting the message below in "app.Run()" method after I initiate "app.Dispatcher.InvokeShutdown()".

    "An attempt has been made to free an RCW that is in use.  The RCW is in use on the active thread or another thread.  Attempting to free an in-use RCW can cause corruption or data loss."

    I have changed the add-in to create a new thread and a new Application within the thread with ShutdownMode set to OnExplicitShutdown - all this "add-in startup". I have also added InvokeShutdown() in "add-in shutdown" (this is where the add-in crashes with the message from above).

    At the point where I want to bring my modal WPF window I actually do a "app.Dispatcher.Invoke()" with a delegate that opens WPF window (in a new thread obviously). Since I have changed the ShutdownMode, the Application is not auto-destroyed. It is enough to open the WPF window once to get experience crash upon quiting Word. I can open my modal WPF window numerous times and all is well until I try to quit Word.

    If I leave the default value of ShutdownMode, then the Application quits as soon as the WPF window is closed. After trying to quit Word, crash does not occur but I cannot re-open my WPF window more than once because the Application has quit its Run() method. Ok, so I though to myself, as soon as the old Application quits, I will fire up a new one to serve a future WPF window request. But then I get the exception that I can't have more than app in an AppDomain. There is obviously a delay before a previously active application is eradicated.

    My WPF window is pure WPF and I found out that RCW has something to do with ActiveX which I don't use. Basically, I have lost too much time to make a trivial thing to work. I am not sure what else to try. It seems like WPF sucks when host is not WPF. :(

    Thursday, September 16, 2010 2:51 PM
  • Hello again,

    I have created a VSTO sample with WPF window. Would you please test it in your side, and see if it also has the same scenario: http://cid-bb22dac51925d7b3.office.live.com/self.aspx/.Public/WPFExcelAddIn.rar. In my side, I did not see this slowness to quit

    I notice you mentioned the Application.Run. Do you have any macro to run? Also here is a reply from Geoff Darst in this thread which might help you: http://social.msdn.microsoft.com/Forums/en-US/vsto/thread/365a1580-98f7-4954-aa0f-e569093a78c6.

    Have a nice weekend.

    Best regards,
    Bessie Zhao - MSFT
    MSDN Subscriber Support in Forum
    If you have any feedback of our support, please contact msdnmg@microsoft.com.


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Friday, September 17, 2010 9:52 AM
  • Hello Bessie,

    Thanks for trying to help me out.

    I have wasted another day in experiments and trying to figure out what was wrong and how to fix. I have downloaded your sample and tried it out and I experience a 12 second delay before Excel finally quits. This comes as a consequence of showing your WPF window. If I don't do that, Excel shuts down normally. I have captured a video so you don't have to trust my words only.

    Ok, I see your sample is using NET4 and is probably an Excel 2010 addin.

    My add-in is an Office 2007 created and built in Visual Studio 2010 with NET3.5 support. During my experiments from last night I have found the possible cause of all this silly behavior (at least the RCW errors I was recently getting).

    This is a VS2010 oddity (if not a bug). When one creates a brand new Word or Excel 2007 add-in project for NET3.5 from withing VS2010, and then immediately closes and reopens it, VS2010 will ask for a project upgrade!!! This upgrade changes .csproj significantly.

    What I have tried is firing up VS2010, creating a new Word 2007 project and putting all the WPF bits in so I could reproduce the issues I was having (delays, RCW exceptions, etc). NONE of them occurred! Then I closed the project, reopened it, VS2010 asked me to upgrade which I did. After I merely rebuilt the project after upgrade, I immediately got RCW exception problem upon closing Word. So go figure!

    I tracked .csproj changes to one significant upgrade change. The upgrade process replaces this:

     

        <ProjectProperties HostName="Word" HostPackage="{D2B20FF5-A6E5-47E1-90E8-463C6860CB05}" OfficeVersion="12.0" VstxVersion="4.0" ApplicationType="Word" Language="cs" TemplatesPath="" DebugInfoExeName="#Software\Microsoft\Office\12.0\Word\InstallRoot\Path#WINWORD.EXE" DebugInfoCommandLine="/w" AddItemTemplatesGuid="{147FB6A7-F239-4523-AE65-B6A4E49B361F}" />
    

    ...with this...

     

     

        <ProjectProperties HostName="Word" HostPackage="{D2B20FF5-A6E5-47E1-90E8-463C6860CB05}" OfficeVersion="14.0" VstxVersion="4.0" ApplicationType="Word" Language="cs" TemplatesPath="VSTOTemplates" DebugInfoExeName="#Software\Microsoft\Office\14.0\Word\InstallRoot\Path#WINWORD.EXE" DebugInfoCommandLine="/w" AddItemTemplatesGuid="{147FB6A7-F239-4523-AE65-B6A4E49B361F}" />
    
    
    If I try to change it back, VS2010 requires another upgrade. And the upgraded project gives me grief. I am beginning to think that going back to VS2008 for Office 2007 support might be the only way. Not sure if that will fix WPF issues though.

     

    Just to make sure I mention this in one place, I am building Office 2007+ add-ins with NET3.5 using Visual Studio 2010 on a Windows 7 x64 with Office 2010 installed.

    Friday, September 17, 2010 11:08 AM
  • The project upgrade behavior you're seeing is by design in your scenario. By default, when you open an Office project, Visual Studio checks to see what version of Office the project targets, and compares this with the version of Office you have installed on your development computer. If you have a later version of Office installed, then Visual Studio automatically updates the project to target the installed version (Office 2010 in your case). Unfortunately, the UI displayed by Visual Studio for this process is a little confusing - it would be much better if it displayed some more helpful UI instead of the general Project Upgrade wizard, but I believe the UI text in the current wizard does include a paragraph that describes what the wizard does to Office projects.

    If you want to stop Visual Studio from automatically upgrading Office projects to the version of Office you have installed, open up the Tools->Options dialog box, and on the Office Tools->Project Upgrade node, clear the "Always upgrade to installed version of Office" check box. For more details, see http://msdn.microsoft.com/en-us/library/bb625070.aspx and http://blogs.msdn.com/b/vsto/archive/2010/04/15/upgrading-vsto-projects-to-use-with-visual-studio-2010-navneet-gupta.aspx.

    If you want to build Office 2007 add-ins that target .NET Framework 3.5 (that is, add-ins that are compiled against the Office 2007 PIAs), the general recommendation is to have Office 2007 installed on your development computer, rather than Office 2010. It is possible to build Office 2007 add-ins when you have Office 2010 installed (see "Primary Interop Assemblies for Microsoft Office" in http://msdn.microsoft.com/en-us/library/bb398242.aspx), because Visual Studio installs a private copy of the Office 2007 assemblies that it uses to build the projects. However, if Office 2007 is not actually installed on the computer (and the Office 2007 PIAs are not installed in the GAC), you will run into problems when you try to run/debug the project.

    All that said, I'm not sure if this is what is causing the WPF behavior you're seeing...


    This posting is provided "AS IS" with no warranties, and confers no rights.
    Friday, September 17, 2010 5:34 PM
    Answerer
  • Hi and thanks for your extensive answer.

    It is kind of shame to have to have the exact Office version one wants to develop against. I understand this is a recommendation and in my case the "unsupported" works just as good for now. Not sure about WPF issues though. My conclusion is that the project upgrade introduced WPF issues.

    I have unchecked the "upgrade option" and so I will see how that treats me. In the meantime, your last paragraph bothers me a lot. Are you saying that since Office 2007 add-ins are built against Office 2007 PIAs, they are not really compatible with Office 2010? You seem to imply that Office 2007 add-ins can potentially happily work on my development machine because of private PIAs copy but does that really mean that Office 2007 add-ins are not generally compatible with Office 2010 because of the lack of 2007 PIAs?

    Or to put it differently, does this mean that in order to support both Office 2007 and 2010, one must develop both a 2007 and 2010 add-in?

    Sorry for the confusion. Thanks a lot!

    Monday, September 20, 2010 8:20 PM
  • RE: "Are you saying that since Office 2007 add-ins are built against Office 2007 PIAs, they are not really compatible with Office 2010?"? Just the opposite: Office 2007 add-ins are compatible at run time (on end user computers) with Office 2007 and Office 2010. This is because Office 2010 includes "binding redirect" assemblies that redirect calls by an Office 2007 add-in into the corresponding Office 2010 PIA (see "Binding Redirect Assemblies" in http://msdn.microsoft.com/en-us/library/15s06t57.aspx).

    The point of my last paragraph was that in order to build an Office 2007 add-in, you should do so on a development computer with Office 2007 installed (not Office 2010). The fact that Visual Studio installed private copies of the 2007/2010 PIAs for development purposes allows you to get away with building an Office 2007 add-in on a development computer where you have Office 2010 installed; however, you will not be able to debug/run the project in this scenario.

    The following article provides more details about which types of projects can be run in different versions of Office: http://msdn.microsoft.com/en-us/library/bb772080.aspx.

    In short, to develop a single add-in that targets both Office 2007 and Office 2010 in Visual Studio 2010, you have two main options:

    • Target the .NET Framework 3.5, and develop an add-in that targets Office 2007. This add-in will work on end user computers with Office 2007 or Office 2010 installed, but it will be restricted to features that are available in Office 2007.
    • Target the .NET Framework 4, and develop an add-in that targets Office 2010 or Office 2007. By default when you target the .NET Framework 4, all PIA types used in your add-in are embedded in your add-in assembly, which effectively "decouples" your add-in from a specific version of the PIA at run time. If your project targets Office 2010 and you want to use Office 2010-specific features when your add-in is loaded in Office 2010 but still have your add-in work fine in Office 2007, you can use a strategy like the one outlined here

     


    This posting is provided "AS IS" with no warranties, and confers no rights.
    • Marked as answer by Bessie Zhao Thursday, September 23, 2010 10:09 AM
    Monday, September 20, 2010 9:00 PM
    Answerer
  • Here is my final conclusion. Considering my exotic system and requirements I seem to have found a winning combination. All it takes for my WPF add-in to function normally without any RCW related or other exceptions is to merely copy the <ProjectProperties> section of the .csproj file from an Office 2007 compatible add-in back to my project (which was messed up because of an unwanted upgrade).

    I also instructed Visual Studio not to upgrade my Office projects by changing VS Options as previously advised.

    After merely rebuilding the solution, I have no issues from before. Suddenly all is well.

    What is the big change introduced by different <ProjectProperties> sections? How does this affect the add-in? The only obvious change I am currently experiencing is the fact that I can no longer run or debug my add-ins unless I explicitly attach to an Office process. I used to be able to F5 or Ctrl+F5.

    • Marked as answer by Bessie Zhao Thursday, September 23, 2010 10:10 AM
    Tuesday, September 21, 2010 11:25 AM
  • Hi

    I know is an old post. But I'm having the same issue on Excel and cannot find any fix for the issue.

    I've installed the new .NET Framework 4.7.2 and as well the new VSTO (10.0.60825) runtime

    https://www.microsoft.com/en-us/download/details.aspx?id=54251
    https://www.microsoft.com/net/download/dotnet-framework-runtime

    Very appreciated if anyone can help resolve this issue and we have about 50 users have this issue when closing Excel with the VSTO adding using the CustomTaskPane.

    Regards,
    David
    Thursday, May 3, 2018 4:42 AM
  • We found a solution for this problem.

    You have to set an AppSwith in the framework

    Public Sub EnablePointerSupport()
    AppContext.SetSwitch("Switch.System.Windows.Input.Stylus.EnablePointerSupport",True)
    End Sub

    You can find more information about it here and here.


    Thursday, November 21, 2019 10:13 AM