none
Update KB908002 not installing during word-addin setup RRS feed

  • Question

  • Hello devs, Im working on a setup project to install an office addin.  Im using VS2005 and .NET 2.0.  Im trying to get the Shared Add-in Support Update for the Microsoft .NET Framework 2.0 (KB908002) components (lockbackRegKey.msi,  office2003-kb907417sfxcab-ENU.exe, extensibilityMSM.msi) to install along with my setup project. 

    I have installed the KB908002 update on my development machine and included it as a prerequisite in my setup project in order to have these components installed along with my solution.  When I run my setup.exe file I get the dialog asking if I want to install the shared addin components on to the machine but when I press install I receive the following error:

    The following package files could not be found:
    C:\Documents and Settings\Administrator\Desktop\KB908002\extensibilityMSM.msi
    C:\Documents and Settings\Administrator\Desktop\KB908002\lockbackRegKey.msi
    C:\Documents and Settings\Administrator\Desktop\KB908002\office2003-kb907417sfxcab-ENU.exe

    See the setup log file located at 'C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\VSDB9.tmp\install.log' for more information.

    Im not really sure why it is looking to the desktop for these files.  I was under the assumption these files would have been included in my setup project and be run from there.  I am also testing this installer on a Virtual Machine with XP Pro SP2 and Office 2003.  Any help would he very much appreciated.

     

    Thursday, June 22, 2006 10:51 PM

Answers

  • Yes, that's how the bootstrapper feature in VS works - you need to distribute the whole folder, because all that setup.exe does is call the KB's MSIs that it expects in a fixed location relative to its own location in the folder. And then it calls your project's MSI.

    Not sure I understand why this is a problem though. Your setup.exe still needs to call your MSI that's a separate file in that folder as well, so it's not like you can just distribute setup.exe alone and expect that to work (even without KB908002). Am I missing something?

    Friday, June 23, 2006 9:10 PM

All replies

  • This is odd.

    Have you verified that VS succesfully included the KB908002 folder in your project's deployment folder? (That is the folder where your project's setup.exe gets put into.)  The setup.exe built by VS should look inside that folder when executing.

    Friday, June 23, 2006 8:39 PM
  • Yes the KB908002 folder is in my project deployment folder and when I run the setup.exe from that location with the folder it installs fine.  However I want to be able to distribute my setup.exe without having to distribute the KB908002 folder along with it as that would defeat the purpose of having one setup file that installs my addin and all the pre-requisites it requires.  Are you saying that I need to distribute this folder along with my setup.exe?
    Friday, June 23, 2006 8:45 PM
  • Yes, that's how the bootstrapper feature in VS works - you need to distribute the whole folder, because all that setup.exe does is call the KB's MSIs that it expects in a fixed location relative to its own location in the folder. And then it calls your project's MSI.

    Not sure I understand why this is a problem though. Your setup.exe still needs to call your MSI that's a separate file in that folder as well, so it's not like you can just distribute setup.exe alone and expect that to work (even without KB908002). Am I missing something?

    Friday, June 23, 2006 9:10 PM
  • Thanks for the reply.  Since the documentation for this update was a little scarce it led me to believe that it would install the necessary fixes without having to actually distribute those files to the deployment machine.  It's not a problem at all.  I was just hoping to get it all done with one distributable file for convenience.  Guess I'll have to wait until this fix is implemented in a service pack :).  Thanks a bunch.

    Friday, June 23, 2006 9:25 PM
  • Sorry you can't get it to work in the way you'd like.

    To be honest though, you might not see much of an improvement in an Sp to fix this... This is a surpisingly tricky issue to fix actually. It's been considered for an upcoming Sp1, but we couldn't find a better solution than what the KB is already providing.

    The problem is that the underlying issues that the KB is addressing are issues in pieces of software that aren't easily fixable to start with, and if they're not all fixed at the same time, then that could cause other problems. One problem is in the CLR (the .Net framework) itself - that's what the lockbackRegkey.msi is fixing. Another one is in Office2003 - that's what the otkloadr update is fixing. And another one is in VS's shared addins features - and that's what the extensibilityMSM.msi is for.

    The surest way to get them all fixed at the same time when your addin is installed is by deploying the three fixes via the bootstrapper along with your addin.

    We found that the best we could theoretically do here is put KB908002 into VS directly, so that you wouldn't have to download it. But that's pretty much where the improvement would have to end. It'd still work the same way as the KB does - which does not solve your single-file deployment problem.

    Office addin development should get much better in Orcas though, and even long before then, with Cypress. Check out our Cypress planning: http://blogs.msdn.com/vsto2/archive/2006/06/08/622538.aspx. For one thing, VSTO Cypress add-ins will not have any of the problems that KB908002 is meant for.

    So instead of waiting for a future SP which might or might not improve much in this area, I'd recommend waiting for Cypress instead and building Office add-ins on top of it, rather than IDTExtensibility2.

    Hope this helps 

    Friday, June 23, 2006 9:56 PM
  • The need to use the bootstrapper is understandable. What is harder to understand is in an environment where admins need to do the installation and regular users have no rights to do that, that the fixes are not on machine level, but for the user who installs those. That means after admin installation the installation is not ready for end-user of that same machine. So, next the regular user needs to log on to the machine, and apply the same fix by launching the setup.exe. It will crash when proceeded to the MSI launch stage, as there are no rights to install. This same problem has been reported in absolutely too many posts, but few, if any solutions.
    Tuesday, June 10, 2008 7:33 AM
  • lockbackRegKey.msi seems to install a registry key for the current user:

    [HKEY_CURRENT_USER\Software\Classes\Interface\{000C0601-0000-0000-C000-000000000046}]

     

    This makes the hotfix (or part of it) to work for the current user, which in my case is the administrator, who actually has the right to install anything on the workstation.

    Next, the same fix needs to be made to work for the actual user of the workstation, for whom the application is installed for.

    I tried to add to registry this new item, which was missing from there:

    [HKEY_LOCAL_MACHINE\Software\Classes\Interface\{000C0601-0000-0000-C000-000000000046}]
     
    First tests show that the addins actually seem to work for other users after this fix.
     
    Is this a solution to the problem? Time and further tests will tell. Looks promising at the moment, though.
    Still wondering why the hotfix was not made properly originally... has cost thousands of hours developer time all around the world.
    Wednesday, June 25, 2008 9:37 AM
  • Eniort

    DId this resolve your problem.  I am fighting exacty the same issue.    It only affects Excel2002.  ExcelXP + do not have the issue.

    David
    Friday, June 27, 2008 5:09 PM
  • I made with Wix a msi file which writes this one registry entry to HKLM. Next, added that msi to the bootstrapper setup.exe. Tests with clean virtual machines and this fix have worked as planned. The office XP addins become nicely visible for other users of the virtual machine than only the one who actually installed it.

    It did resolve my problem, but was the fix 100% for all possible situations? That I can not say, but nothing problematic has come up yet. 

     

    UPDATED INFORMATION FOR Office 2003:

    VSTO Second Edition, Office 2003 add-ins based on VSTO, addins built with Visual Studio 2005, in other words .NET Runtime 2.0.

     

    Addins are installed by the product installer (msi), and the above fix is part of that.

    Installation in the test machines work just nice, but at a customer, addins did not load to the host Office applications.

    As the addins are registered in HKLM, those are not  visible at all in the COM addins list of the host application, like Word, Excel.

    So, after installation the addins do not show, and no blocked items in the host application, and nothing in the COM addins list.

    I changed manually the HKLM registration of one of the addins to HKCU, and tried again. (Obviously, as we all know already, a failed attempt of loading an addin means that it is "turned off" in the registry with the LoadBehavor value from "3" to "2")

    After this, the COM addins list of Word showed the addin, and said there was a problem loading it.

    So, something is wrong, but what?

     

    Just wondering why the Microsoft Office development team has made the decision not to tell details of the error at all. Why not write the details to Event Log, or something? And I know I am not alone with this issue.

     

    Microsoft documentation about the installation of Office 2003 addins say, that PIAs should not be installed by the application, as those are already installed by the Office 2003 installer. (That again is then different for Office XP addins).

    So, PIAs should be there, but were not. To find out if Office 2003 PIAs are installed, go to c:\windows\assembly, and look for items like Microsoft.Office.Interop.Word, or stdole.dll. If not there, PIAs are not installed.

     

    All the badly working machines had a common feature. They had Microsoft Works installed earlier, before installing Microsoft Office. If I have understood right, Works includes a somewhat stripped-down version of Word. Are the PIAs missing in the Works word installation, and the Office installer thinks Word is properly installed, and does not install the PIAs? Certainly looks that way.

     

    Anyways, after some 12 hours (a night well spent), it became obvious that PIAs were missing from the machine.

    Downloaded those and installed, turned the registry LoadBehavors back to "3" and gave it a try. Addins became visible. Success.

     

    Final note: developer documentation around Office addins, VSTO, installation problems, and different Office versions are contradictory. Do not believe just one source, even if from Microsoft. The Office as a development environment is so complex that they don't seem to have one version of the truth themselves.

    Friday, June 27, 2008 5:54 PM
  • I did the same on a clean Virtual Machine as well.   My add-in is visible to other than install users for xl-xp !!  Yea!!!


    My theory.   I think  "office2003-kb907417sfxcab-ENU.exe" must add this key in a proper way so Xl-2003 works.    Since this installer dails for Excel XP  the key does not get added correctly from lockbackregkey.msi


    Thanks for replying  

    David
    Friday, June 27, 2008 6:05 PM
  • I am trying to include KB908002 in a Visual Studio 2005 setup project for distribution to customers who have both Office 2003 and Office 2007.    In testing the installer on an Office 2007 machin, I am running into a problem.   When I run the bootstrapper, it asks me if I want to install KB908002, I say "yes", it tries to install it, and then Windows Installer says that an error occurred.   When I inspect the log I see that it says "Status of package 'Shared Add-in Support Update for Microsoft .NET Framework 2.0 (KB908002)' after install is 'InstallUnknown'"   Why is it saying this?   Is it because I have Office 2007 rather than Office 2003?   Why would it even attempt to install KB908002 on a machine that does not have Office 2003 on it?


    Installation of components 'Shared Add-in Support Update for Microsoft .NET Framework 2.0 (KB908002)' was accepted.
    Copying files to temporary directory "C:\Users\JIMBLA~1\AppData\Local\Temp\VSDBEBF.tmp\"
    Copying from 'C:\Users\Default\Documents\CG_Dev\V3.1\_CG_Distributable\OnePagerXL Release\KB908002\extensibilityMSM.msi' to 'C:\Users\JIMBLA~1\AppData\Local\Temp\VSDBEBF.tmp\KB908002\extensibilityMSM.msi'
    Copying from 'C:\Users\Default\Documents\CG_Dev\V3.1\_CG_Distributable\OnePagerXL Release\KB908002\lockbackRegKey.msi' to 'C:\Users\JIMBLA~1\AppData\Local\Temp\VSDBEBF.tmp\KB908002\lockbackRegKey.msi'
    Copying from 'C:\Users\Default\Documents\CG_Dev\V3.1\_CG_Distributable\OnePagerXL Release\KB908002\office2003-kb907417sfxcab-ENU.exe' to 'C:\Users\JIMBLA~1\AppData\Local\Temp\VSDBEBF.tmp\KB908002\office2003-kb907417sfxcab-ENU.exe'
    Running checks for package 'Shared Add-in Support Update for Microsoft .NET Framework 2.0 (KB908002)', phase BeforePackage
    The following properties have been set for package 'Shared Add-in Support Update for Microsoft .NET Framework 2.0 (KB908002)':
    Running checks for command 'KB908002\lockbackRegKey.msi'
    Result of checks for command 'KB908002\lockbackRegKey.msi' is 'Install'
    Running checks for command 'KB908002\extensibilityMSM.msi'
    Result of checks for command 'KB908002\extensibilityMSM.msi' is 'Install'
    Running checks for command 'KB908002\office2003-kb907417sfxcab-ENU.exe'
    Result of checks for command 'KB908002\office2003-kb907417sfxcab-ENU.exe' is 'Install'
    'Shared Add-in Support Update for Microsoft .NET Framework 2.0 (KB908002)' RunCheck result: Install Needed
    Verifying file integrity of C:\Users\JIMBLA~1\AppData\Local\Temp\VSDBEBF.tmp\KB908002\lockbackRegKey.msi
    Verifying file hash
    Installing using command line '"C:\Windows\system32\msiexec.exe" -I "C:\Users\JIMBLA~1\AppData\Local\Temp\VSDBEBF.tmp\KB908002\lockbackRegKey.msi" -q  /quiet'
    Process exited with code 0
    Verifying file integrity of C:\Users\JIMBLA~1\AppData\Local\Temp\VSDBEBF.tmp\KB908002\extensibilityMSM.msi
    Verifying file hash
    Installing using command line '"C:\Windows\system32\msiexec.exe" -I "C:\Users\JIMBLA~1\AppData\Local\Temp\VSDBEBF.tmp\KB908002\extensibilityMSM.msi" -q  /quiet'
    Process exited with code 0
    Verifying file integrity of C:\Users\JIMBLA~1\AppData\Local\Temp\VSDBEBF.tmp\KB908002\office2003-kb907417sfxcab-ENU.exe
    WinVerifyTrust returned 0
    File trusted
    Installing using command line '"C:\Users\JIMBLA~1\AppData\Local\Temp\VSDBEBF.tmp\KB908002\office2003-kb907417sfxcab-ENU.exe"  /quiet'
    Process exited with code 1614
    Running checks for package 'Shared Add-in Support Update for Microsoft .NET Framework 2.0 (KB908002)', phase AfterPackage
    The following properties have been set for package 'Shared Add-in Support Update for Microsoft .NET Framework 2.0 (KB908002)':
    Running checks for command 'KB908002\lockbackRegKey.msi'
    Result of checks for command 'KB908002\lockbackRegKey.msi' is 'Install'
    Running checks for command 'KB908002\extensibilityMSM.msi'
    Result of checks for command 'KB908002\extensibilityMSM.msi' is 'Install'
    Running checks for command 'KB908002\office2003-kb907417sfxcab-ENU.exe'
    Result of checks for command 'KB908002\office2003-kb907417sfxcab-ENU.exe' is 'Install'
    'Shared Add-in Support Update for Microsoft .NET Framework 2.0 (KB908002)' RunCheck result: Unknown
    Launching Application.
    Using MsiInstallProduct with package path 'C:\Users\Default\Documents\CG_Dev\V3.1\_CG_Distributable\OnePagerXL Release\OnePager Express Installer.msi' and command line ''
    MsiInstallProduct returned '1638'
    Error:
    Status of package 'Shared Add-in Support Update for Microsoft .NET Framework 2.0 (KB908002)' after install is 'InstallUnknown'

    ...Jim
    Monday, August 17, 2009 8:51 PM