none
Unable to find assembly when running as Office add-in RRS feed

  • Question

  • Hi All,

    I am seeing some severely weird binding behaviour and was hoping someone might be able to help me.

    I have written an Office add-in, which includes a managed .NET assembly, which is wrapped in a native COM shim to interface with the Office add-in API.  On every machine in the world bar one, it works fine.

    On this one machine, I can't instantiate the add-in object; it fails with a catastrophic automation error.  When I use fuslog to examine the binding failure in detail I see that it's only looking in one directory for the assembly (c:\Program Files\Microsoft Office\Office10), rather than in the directory in which it's actually registered (c:\Program Files\MyPlugin), or the GAC.  I’ve tried cleaning out all old entries from registry prior to installing, but the problem persists.

    I can get it working by unregistering the files, copying them into the Office10 directory, and registering them there.  Needless to say I'm offended by the level of hackery involved with this workaround.

    I'd be very grateful for any pointers, or suggestions as to how I might go about further tracing the problem (beyond using fuslog).

    Yours,
    Duncan Bayne

    Thursday, September 11, 2008 12:02 PM

Answers

  • Depending on the version of .Net your addin targets, another addin may be trumping your version and providing the catestropic failure. I ran into that and published this in the VSTO forum  Long running Working VSTO application RIP. The hint you will see is that the error thrown will have a different .Net version than the one it should be running.
    William Wegerson (www.OmegaCoder.Com)
    • Marked as answer by Zhi-Xin Ye Tuesday, September 16, 2008 12:17 PM
    Thursday, September 11, 2008 3:38 PM
    Moderator