none
<name>.dll is not a valid Office AddIn RRS feed

  • Question

  • I have two AddIns that are extremely similar - one goes for Excel, one goes for Word.  These were developed in Visual Studio 2010 and VSTO.  BOTH of these AddIns install perfectly on every Windows 7 / Office 2010 machine we try.  The Excel AddIn installs perfectly on any XP / Office 2010 machine.  But we continue to have these problems...

    The Word AddIn WILL NOT install on any machine other than Windows 7 / Office 2010.  We tried XP, and Vista, and Office 2007 as well - NONE of these will install ONLY the Word AddIn.

    Instead we get this error... "[Folder name] / [AddIn name] is not a valid Office Addin"  -  How can it NOT be a valid AddIn if it installs on EVERY Win7 / Office 2010 machine we try???

    We have made sure that all pre-requisites (according to MS) are installed on EVERY machine we try - so pre-reqs are NOT the problem.

    3 Key questions here...

    • What causes the error "...is not a valid Office Addin"???  We KNOW this has to be wrong as these install fine on EVERY Win7 / Office 2010 machine we try.
    • Is there any way to manually tweak some XML (or something) to "force" the Word version AddIn to load?  The install runs fine, no errors, but the AddIn itself never loads.
    • I have been through BOTH of these projects and they are, as mentioned extremely similar - All project and Setup elements are IDENTICAL (expect for obviously individual GUIDs and the verisons of supporting files needed for Excel versus Word), so how can two so similar AddIns have ONE work, the OTHER doesnt?

    Thank you in advance for any answers, suggestions or comments.


    • Edited by B_E_L Monday, July 11, 2011 4:37 PM format
    Monday, July 11, 2011 4:35 PM

Answers

  • In Office 2010, if you include the add-ins registry keys in your MSI, they are written upon install.

    I'm thinking the article you referece might be referring to Office 2007.  In that version add-ins needed to load into the HKCU hive and you have/had to piggy back on a method that the Office apps do use at first run to load your Office add-in.  For more info see this article and its links:

    http://blogs.msdn.com/b/vsto/archive/2010/03/08/deploying-your-vsto-add-ins-to-all-users-saurabh-bhatia.aspx

    If you're using Click-Once I can't comment since I don't use that method of deployment for my apps.


    Kind Regards, Rich ... http://greatcirclelearning.com
    • Marked as answer by B_E_L Tuesday, July 12, 2011 7:51 PM
    Tuesday, July 12, 2011 6:17 PM
  • Hi BEL,

    Is the Windows Registry Word add-ins manifest string value formatted like this?

    C:\Program Files (x86)\Great Circle Learning\LeaderGuide Pro\Pro 8\dll\George4ppt.vsto|vstolocal

    And does the dll & manifest names all correspond?  So for my example above they look like this:

    George4ppt.dll

    George4ppt.dll.manifest

    George4ppt.vsto

    George4ppt.xml


    Kind Regards, Rich ... http://greatcirclelearning.com
    • Marked as answer by B_E_L Tuesday, July 12, 2011 7:51 PM
    Tuesday, July 12, 2011 3:44 PM

All replies

  • One comment/question that I have is, did you develop these add-ins on a machine of the lowest common denominator?  Meaning, if you developed it on an Office 2010 machine the likelihood of it being able to run without change on an Office 2007 machine is pretty low.

    Upward compatibility works, downward doesn't.


    Kind Regards, Rich ... http://greatcirclelearning.com
    Tuesday, July 12, 2011 1:43 AM
  • Rich,

    Thanks for the reply.  and yes - this was developed on an Office 2010 machine / Win7.

    Do you know of any documentation of how I might rattle this back to work on an XP box?  (would have Office 2010)

    If I redevelop this under XP, is it likely that I will have to have versions for each OS?  (if you know this answer?)

    Thanks very much for your help.

    - BEL

     

     

    Tuesday, July 12, 2011 1:49 PM
  • Hi BEL,

    I was referring to Office only, not the OS. I regularly move between developing with VS2010 using Office 2010 on both XP and Win 7 platforms and have not experienced any issue for add-ins to Word, Excel, and PowerPoint.  When I'm going to offer the add-in for Office 2007 I convert it on a development machine that has VS2010, Office 2007, and XP.

    Maybe there's literally something about the dll name that is conflicting. Can you post the names of files from your Bin\Release folder?


    Kind Regards, Rich ... http://greatcirclelearning.com
    Tuesday, July 12, 2011 2:09 PM
  • Hi Rich...

    Gotcha - Its the Office version you are referring to.

    The releaes names are "RemediaLink_Excel" and "RemediaLink_Word".  Do you think that would cause a conflict especially based on the (in some cases) error message of "RemediaLink_Word.DLL is not a valid Office AddIn"?

    Also, this morning we have had our first report of problems on a Win7 32 bit with Office 2010 machine...  Oy!

    Thanks for your help - its appreciated.

     

     

     

    Tuesday, July 12, 2011 3:16 PM
  • Hi BEL,

    Is the Windows Registry Word add-ins manifest string value formatted like this?

    C:\Program Files (x86)\Great Circle Learning\LeaderGuide Pro\Pro 8\dll\George4ppt.vsto|vstolocal

    And does the dll & manifest names all correspond?  So for my example above they look like this:

    George4ppt.dll

    George4ppt.dll.manifest

    George4ppt.vsto

    George4ppt.xml


    Kind Regards, Rich ... http://greatcirclelearning.com
    • Marked as answer by B_E_L Tuesday, July 12, 2011 7:51 PM
    Tuesday, July 12, 2011 3:44 PM
  • Hi Rich,

    Well, we've had a bit of a breakthough - we found that though the Excel Addin is registering, the Word one IS NOT.  And when I added the regkeys manually (to Office\Addins...) Bingo!  The Addin goes through its first time "Verify Publisher" and installs...

    This led us to review the installs for both AddIns.  These were done largely identically (or so I thought) and yet we have noticed two problems with the Word version: #1 There are no Launch conditions for the Word version, whereas there are for the Excel version.  Not sure how these got overlooked.  And #2, Although we have the Advanced Compile Options set to .NET 3.5, the Install is showing that .NET 4.0 should installed.  We are working to correct these differences now, and then will test again. 

    One question: We found a doc on the Web that says Office Addins dont write their registry values during Install.  They write them on the first run.  Do you know if that is true?

    Now that we know its the registry values, at least I can get the QA guys up and testing what the Addin is intended to do - we will keep working through the other issues.

    Thanks

    Tuesday, July 12, 2011 5:52 PM
  • In Office 2010, if you include the add-ins registry keys in your MSI, they are written upon install.

    I'm thinking the article you referece might be referring to Office 2007.  In that version add-ins needed to load into the HKCU hive and you have/had to piggy back on a method that the Office apps do use at first run to load your Office add-in.  For more info see this article and its links:

    http://blogs.msdn.com/b/vsto/archive/2010/03/08/deploying-your-vsto-add-ins-to-all-users-saurabh-bhatia.aspx

    If you're using Click-Once I can't comment since I don't use that method of deployment for my apps.


    Kind Regards, Rich ... http://greatcirclelearning.com
    • Marked as answer by B_E_L Tuesday, July 12, 2011 7:51 PM
    Tuesday, July 12, 2011 6:17 PM
  • Hi Rich,

    We're in good shape now.  As it turns out, the Word AddIn install DID NOT have the registry write or Launch Conditions and once these were fixed, I also checked through for all references to the proper version of .NET.  We carefully updated the installs to match for both the Excel and Word versions and now both load fine - so far we have tested them on XP and Win7 and they both load and run fine.

    Thanks for the link to the article - no, that was not the one I was mentioning, but it is some good useful information so we're bookmarking that.

    I also do not like using Click-Once.  We are long-time InstallAware users - although on these two AddIns (as we have done on a couple others) we went with the Visual Studio Installer Project.  I dont really like how that is kind of "all over the place" interface-wise, but seems the best for AddIns and we have learned a big lesson there to check those much more tightly.

    Once again, Many thanks for your help - you tipped us off to checking the Registry and that started the resolution - its appreciated!

    Regards,

    BEL

    Tuesday, July 12, 2011 7:50 PM