none
Word add in fails to load RRS feed

  • Question

  • I have an integration with my document management system with Microsoft Office. Only the Word add in keeps giving me issues and I don't know why. I get this exception (when suppressing the VSTO display alerts):

    Exception has been thrown by the target of an invocation.

    ************** Exception Text **************

    System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.TypeLoadException: Method 'add_DocumentBeforeSave' of COM event interface 'Microsoft.Office.Interop.Word.ApplicationEvents4_Event' is not present on event provider 'Microsoft.Office.Interop.Word.ApplicationEvents4'.

       at DynamicModule.ns.Wrapped_Application_a9b6a11cc9e24b5abdedcb9eff51eb53.add_DocumentOpen(ApplicationEvents4_DocumentOpenEventHandler )

       --- End of inner exception stack trace ---

       at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor)

       at System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal(Object obj, Object[] parameters, Object[] arguments)

       at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)

       at System.Reflection.EventInfo.AddEventHandler(Object target, Delegate handler)

       at System.Runtime.InteropServices.ComAwareEventInfo.AddEventHandler(Object target, Delegate handler)

       at NetDocuments.Client.WordAddIn.ThisAddIn.InitializeCustom()

       at NetDocuments.Client.WordAddIn.ThisAddIn.Initialize()

       at Microsoft.Office.Tools.AddInBase.Microsoft.Office.Tools.EntryPoint.Initialize()

       at Microsoft.VisualStudio.Tools.Office.Runtime.DomainCreator.ExecuteCustomization.ExecutePhase(ExecutionPhases executionPhases)

       at Microsoft.VisualStudio.Tools.Office.Runtime.DomainCreator.ExecuteCustomization.Microsoft.VisualStudio.Tools.Office.Runtime.Interop.IExecuteCustomization2.LoadEntryPoints(IntPtr serviceProvider)

    What I do is do a full online repair of office and this fixes it, for a bit. Sometimes a day goes by, sometimes 3 but it always comes back. 

    Tuesday, July 16, 2019 9:27 PM

All replies

  • Hello,

    Did you try to debug the add-in? Which code do you have in the DocumentOpen event handler?


    profile for Eugene Astafiev at Stack Overflow, Q&A for professional and enthusiast programmers

    Tuesday, July 16, 2019 11:37 PM
  • The hard part is it only happens on the users machine, not in my environment. Windows version and office build are the exact same. 
    Tuesday, July 16, 2019 11:58 PM
  • Is there any antivirus application installed on the system? Did you try to check the system for viruses?

    profile for Eugene Astafiev at Stack Overflow, Q&A for professional and enthusiast programmers

    Wednesday, July 17, 2019 4:02 PM
  • No Viruses and yes currently has anti-virus. It's a large organization and has an IT department take care of everything. Obviously that doesn't mean it's perfect, but just wanted to point out it's not just a single user. 

    The PIA's are all embedded in the application. I can't figure what else the local machine is missing to not see the method on the interface. I've dug and dug into articles and solutions for this and got stuck and now I'm here.

    Thanks for your replies so far. 

    Wednesday, July 17, 2019 6:51 PM
  • Hi. I saw your post under my similar post, but I'll answer here since this is Word and not MS Project. Sorry you're hitting the same type of frustrating issue that we have been hitting with MS Project!  Ours started happening only in the last year after working without fail for 10 years, so the culprit is either something that has changed in Windows (i.e. Windows 10) or, more likely, something that has changed in MS Office.   Are your problems occurring only with Word for Office 365?

    Your error message sounds like it could be versioning problem in the PIA that you are embedding. Maybe the COM server that is running on your end-users machine does not support an interface that is present in your embedded interop assembly.   Specifically it is looking for an event ApplicationEvents4_Event that is not present in the instance of Word that is running on your users' machines.    

    Did you embed the last official PIA that Microsoft provided in Office 2013?  If so, you might try finding/generating a more recent interop assembly directly from Word for Office 365.   You can find help on doing that if you google around, though I cannot lay my hands on the link right now.

    Hope this helps.



    ...Jim Black


    • Edited by Jim Black CG Thursday, July 25, 2019 3:50 PM typo
    Thursday, July 25, 2019 3:48 PM
  • Do you see the issue on multiple machines or just one?

    Did you try to exclude PIAs from your assembly? Just try adding them anew without embedding.


    profile for Eugene Astafiev at Stack Overflow, Q&A for professional and enthusiast programmers

    Thursday, July 25, 2019 3:59 PM
  • I'm going to try a test build on Monday with the PIA not embedded. 

    Side note: Running Word as admin loads the add-in just fine... This doesn't make sense. Our application builds add-ins for Excel, Word and Outlook. And Excel and Outlook work just fine. Why would Word have access issues to read the interop file and why would running as Admin get around this? 

    Any thoughts? 

    Friday, July 26, 2019 5:49 PM
  • Note that running as Admin also fixed some people's problems with the MS Project PIA not loading in this other discussion thread.   No one has a clue as to why that matters!


    ...Jim Black

    Friday, July 26, 2019 7:35 PM
  • Another thought.  Have you looked at the disassembly of your assembly with the embedded interop to see whether the event is missing after embedding?

    ...Jim Black

    Friday, July 26, 2019 7:38 PM
  • Is there any news after excluding PIAs and re-adding them to a project anew? Did it help?


    profile for Eugene Astafiev at Stack Overflow, Q&A for professional and enthusiast programmers

    Sunday, August 4, 2019 9:12 AM
  • Eugene,

    Unfortunately I'm not privy to the code itself, so relying on the developers to push out the build. Haven't been able to test that yet. 

    Wednesday, August 7, 2019 3:48 PM
  • What I would love to hear from Microsoft is what they changed they messed with their assemblies. And why does running Word as admin load the add-in just fine? 
    Thursday, August 8, 2019 5:02 PM
  • That's the mystery that I'd like to understand, too!

    ...Jim Black

    Thursday, August 8, 2019 6:36 PM
  • Jim,

    I had a user who ended up formatting the computer and doing a fresh install of the OS and now everything works fine for them. Did you ever notice this in your en devours? 

    Thursday, August 8, 2019 6:39 PM
  • Yes, we have had reports of things like that, too.  It's as though there's a configuration that reveals a bug in Windows 10 or Office 365 that makes this happen.  When they rebuild the computer, the configuration goes away so the failure goes away.

    ...Jim Black

    Thursday, August 8, 2019 8:23 PM
  • Here is another forum with assembly issues. It all seems to point back to build 1809. 

    https://social.technet.microsoft.com/Forums/en-US/dbc78d42-dcd8-4d12-901b-c77efb040e6a/officedll-access-denied-to-vsto-addin?forum=Office2016ITPro

    The question is how does on bring this to Microsoft? I'm also curious if skipping 1809 and going straight to 1903 if we would never see this issue? 

    This is very frustrating. 

    Friday, August 9, 2019 2:26 PM
  • I have successfully brought one bug to Microsoft's attention in the past, resulting in a successful resolution.  First I opened a formal support ticket with them under my Microsoft Partner credentials.  Then I went out to one of their feedback ("user voice") forums (in this case it was for MS Project) and drummed up 130 votes for Microsoft to fix the problem.  We got on social media and also communicated with our customers via a blog post to ask them to contact Microsoft via the user-voice forum. It was a large effort and took a lot of time, but it worked.  They eventually put me in touch with a guy at Microsoft who understood what I was talking about, saw the need/urgency, and got it fixed.  But Microsoft does not make it easy to do this sort of thing.

    ...Jim Black


    • Edited by Jim Black CG Friday, August 9, 2019 4:04 PM clarification
    Friday, August 9, 2019 3:50 PM
  • In case we/you might want to do something similar in this case, here's a thread that I started in that case on the forum, and here is the mobilization we accomplished at the "user voice" feedback site by drumming up 130 votes.  Frankly opening the formal support incident with MSFT as a MSFT Partner had no impact and never has had any impact in my 15 years of working with them.  The only thing that worked was the user-voice forum.  I don't know if there is a user-voice forum for the more general problem that we've discovered.  It affects MS Project and MS Word, but it probably affects all COM-Interop integrations with MS Office!  I'm surprised that there are not more people clamoring about this!

    ...Jim Black




    • Edited by Jim Black CG Friday, August 9, 2019 4:06 PM clarification
    Friday, August 9, 2019 4:01 PM
  • Update:

    I have found exactly which file's are giving us issues. The Microsoft.Office.Interop.Word.dll and the Office.dll. There is a windows update (I'm going to be going through the event viewer to find exactly which one) that is rebuilding these files and wiping access to them. It's NOT inheriting from the folder it's put in like you would expect, as the user does have access to those folders. But the dll's end up without access. But Administrators do retain read access, which makes sense why running Word as admin lets the add-in load just fine. 

    We do embed the Word interop assembly, but I'm asking developers to give me a test build which embeds the office.dll as well to see if that helps. Although I doubt it, because even though we embed the Word interop, and I give the user access to the Office.dll, it still doesn't load unless I give them explicit access to the dll in the GAC_MSIL. 

    Once I can find exactly which update is doing this I can post that here. 


    • Edited by jmillerim2 Tuesday, August 13, 2019 7:50 PM
    Tuesday, August 13, 2019 7:48 PM
  • Sounds like you're making progress!  Keep us posted.  I want to understand what you've learned, but I don't quite follow you in these two sentences:  

    It's NOT inheriting from the folder it's put in like you would expect, as the user does have access to those folders. But the dll's end up without access. 

    Can you explain what is meant by "inheriting" and "these folders"?

    In our failure cases, we were putting the Interop assemblies MSProject.dll and Office.dll into the binary folder for our application, which meant that they should have been loaded first, before looking for them in the GAC.   Ordinary users always have read and execute access to these folders, and we know that users had such access when the failures occurred.

    Regarding Windows updates, that's quite interesting, and I hope you can figure out which update is the culprit.  The only thing that makes sense to me about Windows updates is that a Windows update could update assemblies in the GAC or in a System32 folder.  I can't imagine that  Windows update would be so bold as to affect an assembly in an application's binary folder, where we traditionally placed these two assemblies.


    ...Jim Black


    • Edited by Jim Black CG Tuesday, August 13, 2019 8:32 PM italic font on quote
    Tuesday, August 13, 2019 8:31 PM
  • Hi Jim Black CG and jmillerim2,

    My name is Ryan Carter and I am a PM with Desktop App Assure from Microsoft.  We're tracking this issue with an add-in ISV and would appreciate collaborating on this to learn more from the impressive work you have one getting this far.

    Please reach out to me at rycarter @ microsoft .com at your earliest convenience!

    Thanks,

    Ryan

    Tuesday, August 20, 2019 9:15 PM
  • Just so you all are aware, I feel I nailed down the problem. The updates were coming from the Microsoft Store, and specifically the Office App updates. After removing that app the problem hasn't come back. 

    I'm still working with Ryan at Microsoft to help them get what they need to resolve things on their end. 

    Friday, August 23, 2019 4:50 PM
  • That's great news jmillerim2!  I have also been providing diagnostics to Ryan that we generated as we dealt with the issue.  It sounds like you have made more specific identification of the culprit than I was able to.  The only thing that your situation and mine have in common is office.dll, and that would affect LOTS of integrations!  I look forward to hearing the final identification of and fix to of the Office App updates in Microsoft Store, so that we can provide information to our customers.

    ...Jim Black

    Friday, August 23, 2019 5:36 PM
  • I may be wrong about the specific app that's causing the issues. Digging through the machines Appx Packages to see what they have that I don't to narrow this down. 
    Tuesday, August 27, 2019 8:21 PM