none
KB 907417 & 908002

    Question

  • Hi;

    Asking new because I think this got lost in the message it was a reply to...

    Just to confirm, if I have run the latest windows update and it shows no updates for Word, then the fixes in KB907417 should be on my machine - correct?

    I have never run the fix in KB907417 and on my dev machine it has version 7.10.5077.0 but my test system, which shows no pending office updates, has 7.10.3191.0. So it looks like I do have to install it.

    Do we run this same update for Word 2002 and Word 2000? Or is there a different update in their cases?

    And for our customers, I assume we have to point them at this fix? Or will it be included in the Windows update soon? Or can we include it in our install? Does it just update this one dll?

    For KB908002, this is added to the setup program. However, we use WIX for our setup. How do we add this to our setup, and what does it do?

    thanks - dave


    Monday, December 19, 2005 8:43 PM

Answers

  • 1) you can just delete all the UI. Right-click on each of those UI nodes and Delete

    2) I assume you are in the process of moving all of your setup logic from WiX to that VS2005 setup project, right? 

    If so, then there should be no MSIs that you need to invoke from within the VS-built MSI. All you need to do is right click on the Setup project node in the Solution Explorer, click Properties, Prerequisites and then check "Shared Addins Support Update (KB908002)". Note that what VS builds from your setup projects are two files: an MSI and a Setup.exe file. It's the Setup.exe that executes all the prerequisite MSIs associated with KB908002. And it's Setup.exe that your users will need to run to install your solution.

    3) The most reliable way to test if the patches (or your setup program) works is naturally to have a "clean" machine. A recommended testing technique is that you should always have a "clean" image of your machine saved somewhere that you can go back to when doing significant testing of your setup logic. 

    However, for quick-and dirty sanity checks, you can do the following to uninstall the patches (at least partially). (Also make sure you test the setup logic on a machine that does NOT have VS installed on it)

    In Control Panel, go to Add/Remove programs and uninstall the folowing:

    - Shared Add-In Extensibility Update for Microsoft .NET Framework 2.0 (KB908002)

    - Shared Add-In Support Update for Microsoft .NET Framework 2.0 (KB908002)

    Note, that this will do only a partial uninstall. The Office2003 otkloadr patch (and the related regkeys) cannot be uninstalled, so you'll need to re-image the machine with the original unpatched version of Office before confirming that it gets installed properly. (the version of the otkloadr.dll file needs to have the number 5077 in it if it's patched)

    4) You can use the info above (Add/Remove Programs) to confirm that the patches have been installed.

    Additionally, you can check if the following regkey exists in the registry:

    HKCR\Interface\{000C0601-0000-0000-C000-000000000046}

    And on an Office2003 machine, check the version of the otkloadr.dll

    5) No. You cannot add an MSI to another MSI (which is what you're doing by adding that MSI file into the VS setup project). WiX and VS Setup projects don't mix (at least not easily). You need to choose one of the methods and go with it all the way. 

    If you want to keep using WiX, then you need to create your own simple bootstrapper like I described earlier. You can still use VS for it, just not a VS setup project, because that creates a new MSI, which is what you don't want. You just need a regular exe app in a language of your choice pretty much. Or a batch file for that matter should probably suffice, if you can assume .Net is on the target machine already.

    If you want to use VS Setup projects specifically (which makes it easier to distribute the patches) then you'd need to move all of your setup logic from WiX to the VS Setup project.

    I think you'll find it much easier to stick with WiX and just write a simple exe (or a batch file) that installs the prereqs from KB908002 like I described in the previous post.

    ...Also, I'm still looking into trying to make it easier for you. Because we're in the middle of the Christmas season, I won't be able to find the people who can answer some WiX questions that I have until some time next week. If you can wait that long, I might (or not) figure out a much better way for you to do this next week...

    Regards,

    Martin

     

    Friday, December 30, 2005 8:43 PM
  • ...In the meantime, if you'd like a very rudimentary bootstrapper to play with, you can do this:

    1) Create a folder in your application setup folder called KB908002

    2) Copy the three relevant files from VS's KB908002 folder into your KB908002 folder: lockbackRegKey.msi, extensibilityMSM.msi and office2003-kb907417sfxcab-ENU.exe.

    3) Start Notepad and paste the following:

    KB908002\extensibilityMSM.msi
    KB908002\office2003-kb907417sfxcab-ENU.exe /quiet
    KB908002\lockbackRegKey.msi
    MyWiXMSI.msi

    4) Replace MyWixMSI.msi with the actual file name of your Wix-built MSI

    5) Save this as "Setup.bat" in your application setup folder.

    Now Setup.bat is your simplest bootstrapper possible. Just copy your application setup folder to an Office machine now, and then double-click Setup.bat to install it. It should work.

    Not that I recommend doing exactly this for your final product (though that I guess depends on who you are distributing it to), but it's one simple approach you could take if you want to, and refine it further.

    In any case, I'll see if I can find a more elegant solution next week.

    Martin

    Friday, December 30, 2005 9:09 PM

All replies

  • Hi Dave:

    This is actually an issue for the Word team. You should post this question in the Word newsgroup, which you can access here:

    http://msdn.microsoft.com/newsgroups/default.aspx?dg=microsoft.public.word.application.errors&lang=en&cr=US

    Thanks!

    Mike Hernandez
    Community Program Manager
    VSTO Team

    Monday, December 19, 2005 9:33 PM
  • For now, I'm just referencing the answer I provided for your question on that other thread. (Note I still need to get back to you on the redistributability issue related to non-VS2005 setups):

    http://forums.microsoft.com/MSDN/showpost.aspx?postid=173940&siteid=1

    If Windows Update doesn't kick in on your test machine with Office 2003 that still has the older version of otkloadr, then you should run KB907417 on that machine manually.

    Best regards

    Martin

    Tuesday, December 20, 2005 8:14 PM
  • Dave

    Actually, I've just realized that you may already have all the pieces you need to include with your setup. You're using VS2005, so you can install KB908002 on that machine. I don't know much about how InstallShield or WiX work exactly, but I assume the following should be possible:

    1) after you install KB908002 on your VS machine, navigate to the following folder:

    [...]\BootStrapper\Packages\KB908002

    where [...] stands for whatever the path is to this folder (it may vary between different VS installations, so you may need to look for it. On my VSTO machine it's \Program Files\Microsoft.NET\SDK\v2.0\BootStrapper\Packages\KB908002)

    2) You need to include and run the following files from that folder in your setup:

    a) lockbackRegKey.msi - this will fix the CLR issue on Office machines older than Office2003

    b) office2003-kb907417sfxcab-ENU.exe - this patches Office2003

    c) extensibilityMSM.msi - this installs extensibility.dll. You may skip it if you do not need to put extensibility.dll on the user machine.

    If you can do the above from within your setup, then you should be set. This is what the VS2005 bootstrapper does anyway, so by perfoming the above 3 steps you're simply emulating what setup.exe built by VS would do here.

    (BTW - When executing the office2003-kb....exe, you may want to use the /quiet flag to kill the UI that might pop up from that)

    Let me know if this helps

    Martin

    Wednesday, December 21, 2005 8:14 PM
  • Mike, this is actually not for Word. This is related to the otkloadr related patched we've shipped not long ago.

    Martin

    Wednesday, December 21, 2005 8:16 PM
  • Hi;

    That did it.

    thank you very much and have a Merry Christmas - dave

    Friday, December 23, 2005 1:35 AM
  • Houston, we have a problem.

    The three items to install are two msi files and an exe that has a msi inside it. This means we can't use them in our installer - see http://sourceforge.net/mailarchive/message.php?msg_id=12238009

    So... Any chance of getting these as a msm or fidning out exactly what they do?

    thanks - dave

    Friday, December 23, 2005 5:08 PM
  • I see, that means WiX has the same issue we were running into that prevented us from distributing the whole patch as a single MSI and instead we had to rely on the VS bootstrapper. Indeed, if WiX is uses an installer process, then it cannot spawn another installer process from within it (which MSIs and Office patches (exe) inevitably do). That is why a bootstrapper is required to distribute MSIs and the Office patch exe. The bootstrapper is not an installer process, hence it can run MSIs within it.

    Working around this limitation is going to be very tricky (and time consuming) for a number of reasons, so before we try going into that, let me just ask: are you able to consider building a bootstrapper (setup.exe) of your own anyway (either via VS or your own code) which would run the KB908002 patches before starting the WiX installer?  That seems like the easiest way out right now...

    Martin

    Thursday, December 29, 2005 6:33 PM
  • Hi;

    I am reticent about using the bootstrapper approach for two reasons:

    1. The Microsoft recomended approach is a msi file. And I try to follow the recs because it makes software more solid.
    2. The msi by itself works very well with the uninstaller (although no one would ever want to uninstall our products ).

    Is it possible to find out what these 3 patches do? Or is it possible to get a single msi of the three and we tell people to run it first? Or can it be added to the Word update? And in this cases, is there a test we can do during our install so we can tell people they need to update Word in order to run our Add-In?

    I think the "best" approach is that these three fixes are added to the Office auto-update and you post here how we can test to see if they have been run in our installers. So we test for that just as we test for .NET 2.0 and J# 2.0.

    thanks - dave

    Thursday, December 29, 2005 6:40 PM
  • That's understandable, but note that you do not need to give up on any MSIs if you use a bootstrapper. All that the bootstrapper would do is run the MSIs that you already have. Your software is still just as easily uninstallable if you use a simple bootstrapper as it is without it. The bootstrapper could be just a VB app, or a script, or a batch file for that matter. For example, all your bootstrapper "setup.exe" might need to have inside it is (in pseudo-code):

    ShellExecute lockbackRegKey.msi

    ShellExecute office2003-kb907417sfxcab-ENU.exe /quiet

    ShellExecute extensibilityMSM.msi

    ShellExecute yourSoftwareInstallation.msi

    then you should be set. Whatever yourSoftwareInstallation.msi does would still work the way it works today, that is it is fully uninstallable etc. All that the bootstrapper does is run a sequence of installers in addition to your own MSI.

    Does this make more sense?  Is this still unfeasible?

    Knowing what's inside the patches might not help you as much as you might hope, but for what it's worth, here's some extra detail:

    - office2003-kb907417....exe is the most important piece that you need on an Office2003 machine. It a binary patch of the otkloadr.dll file along with a bunch of registry settings.

    - lockbackRegKey.msi - just sets a single reg key, which is sufficient to fix the CLR issue in Office10 and older, but will have undesirable side effects on Office2003 (it will break your customers' VSTO v1 solutions) if applied without the .exe patch from above (from KB907417).

    - extensibilityMSM.msi - this is just the extensibility.dll installer. If you have another way of distributing extensibility.dll, you may not need it.

    Martin

    Thursday, December 29, 2005 7:23 PM
  • Hi;

    If we have to, we have to. We can do this. I just wish Microsoft would follow Microsoft's guidelines and release things like this as a .msm file.

    thanks - dave

     

    Thursday, December 29, 2005 7:36 PM
  • Hi;

    I am trying to do this. A couple of questions.

    1. I want the VS 2005 created setup to have no UI. It appears to not show any UI but it does have all of the UI screens. Do I need to worry about this?
    2. It creates a msi file. Isn't this a problem in that msi files are not supposed to call msi files?
    3. How can I tell if it is working? Do I need to wipe my hard drive and re-install Word and Office and then run it to see if the three hot fixes ran. Or is there a way to uninstall them?
    4. And how do I verify that each ran? What can I look for before & after for each? I know I can look at the version of otkloadr.dll for one of the hot fixes. But how do I check the other two?
    5. I just added my msi as a file to a setup project I created. I did not set any properties anywhere. Is this the best way to do this?

    thanks - dave

    ps - I still think it would be better for MS to have a single fix than to have every programmer writing an Add-In have to go through all of this.

    Friday, December 30, 2005 7:53 PM
  • 1) you can just delete all the UI. Right-click on each of those UI nodes and Delete

    2) I assume you are in the process of moving all of your setup logic from WiX to that VS2005 setup project, right? 

    If so, then there should be no MSIs that you need to invoke from within the VS-built MSI. All you need to do is right click on the Setup project node in the Solution Explorer, click Properties, Prerequisites and then check "Shared Addins Support Update (KB908002)". Note that what VS builds from your setup projects are two files: an MSI and a Setup.exe file. It's the Setup.exe that executes all the prerequisite MSIs associated with KB908002. And it's Setup.exe that your users will need to run to install your solution.

    3) The most reliable way to test if the patches (or your setup program) works is naturally to have a "clean" machine. A recommended testing technique is that you should always have a "clean" image of your machine saved somewhere that you can go back to when doing significant testing of your setup logic. 

    However, for quick-and dirty sanity checks, you can do the following to uninstall the patches (at least partially). (Also make sure you test the setup logic on a machine that does NOT have VS installed on it)

    In Control Panel, go to Add/Remove programs and uninstall the folowing:

    - Shared Add-In Extensibility Update for Microsoft .NET Framework 2.0 (KB908002)

    - Shared Add-In Support Update for Microsoft .NET Framework 2.0 (KB908002)

    Note, that this will do only a partial uninstall. The Office2003 otkloadr patch (and the related regkeys) cannot be uninstalled, so you'll need to re-image the machine with the original unpatched version of Office before confirming that it gets installed properly. (the version of the otkloadr.dll file needs to have the number 5077 in it if it's patched)

    4) You can use the info above (Add/Remove Programs) to confirm that the patches have been installed.

    Additionally, you can check if the following regkey exists in the registry:

    HKCR\Interface\{000C0601-0000-0000-C000-000000000046}

    And on an Office2003 machine, check the version of the otkloadr.dll

    5) No. You cannot add an MSI to another MSI (which is what you're doing by adding that MSI file into the VS setup project). WiX and VS Setup projects don't mix (at least not easily). You need to choose one of the methods and go with it all the way. 

    If you want to keep using WiX, then you need to create your own simple bootstrapper like I described earlier. You can still use VS for it, just not a VS setup project, because that creates a new MSI, which is what you don't want. You just need a regular exe app in a language of your choice pretty much. Or a batch file for that matter should probably suffice, if you can assume .Net is on the target machine already.

    If you want to use VS Setup projects specifically (which makes it easier to distribute the patches) then you'd need to move all of your setup logic from WiX to the VS Setup project.

    I think you'll find it much easier to stick with WiX and just write a simple exe (or a batch file) that installs the prereqs from KB908002 like I described in the previous post.

    ...Also, I'm still looking into trying to make it easier for you. Because we're in the middle of the Christmas season, I won't be able to find the people who can answer some WiX questions that I have until some time next week. If you can wait that long, I might (or not) figure out a much better way for you to do this next week...

    Regards,

    Martin

     

    Friday, December 30, 2005 8:43 PM
  • ...In the meantime, if you'd like a very rudimentary bootstrapper to play with, you can do this:

    1) Create a folder in your application setup folder called KB908002

    2) Copy the three relevant files from VS's KB908002 folder into your KB908002 folder: lockbackRegKey.msi, extensibilityMSM.msi and office2003-kb907417sfxcab-ENU.exe.

    3) Start Notepad and paste the following:

    KB908002\extensibilityMSM.msi
    KB908002\office2003-kb907417sfxcab-ENU.exe /quiet
    KB908002\lockbackRegKey.msi
    MyWiXMSI.msi

    4) Replace MyWixMSI.msi with the actual file name of your Wix-built MSI

    5) Save this as "Setup.bat" in your application setup folder.

    Now Setup.bat is your simplest bootstrapper possible. Just copy your application setup folder to an Office machine now, and then double-click Setup.bat to install it. It should work.

    Not that I recommend doing exactly this for your final product (though that I guess depends on who you are distributing it to), but it's one simple approach you could take if you want to, and refine it further.

    In any case, I'll see if I can find a more elegant solution next week.

    Martin

    Friday, December 30, 2005 9:09 PM
  • Hi;

    My whole goal is to have a single program they download. If it's multiple programs I can just point them at the MS hot fix programs.

    I think for now we'll stick with what we have at http://www.windwardreports.com/downloads.htm where we tell them to run the MS hot fix installers. And we'll add a check to see if they have been installed and send them to our page if not.

    thanks - dave

    Friday, December 30, 2005 10:35 PM
  • Understandable.

    Note though that you can still have a single download, if you package your software inside an IExpress package. Not sure if you've explored this option yet. This is how Microsoft packages many (if not most) of its downloads, even though they are MSIs under the hood.  (for example, the download for KB908002 is packaged that way). You can just put your multiple MSIs and the bootstrapper (like that .bat file) inside the IExpress package, and configure the package to start Setup.bat when it's double clicked. In case you're interested in that, just type "iexpress" on the commandline and you'll see the wizard. The wizard is pretty self-explanatory and easy to use. More documentation can be found at: http://www.microsoft.com/technet/prodtechnol/ie/ieak/techinfo/deploy/60/en/iexpress.mspx.

    Just something you might like to explore, if you haven't checked it out yet.

    Best regards

    Martin

    Friday, December 30, 2005 10:51 PM
  • Hi;

    I'll try that - next year .

    Thanks and have a happy new year.

    - dave

    Friday, December 30, 2005 11:08 PM
  • Thanks, likewise!

    Martin

    Friday, December 30, 2005 11:17 PM
  • Hi;

    Ok, I tried this. But it runs very fast (there is no pause or step for iexpress) and I think what is happening is that it is extracting the files and runs my setup.bat - but it does not have the directory it extracted to as the default directory so the programs are not found.

    What do I need to do?

    thanks - dave

    Saturday, December 31, 2005 6:32 PM
  • Hi;

    Another problem. The two msi programs are not signed (the exe is). So when someone goes to run them, we say they are from Microsoft but that is questionable because "if they were from Microsoft, wouldn't they be signed?"

    Could Microsoft release signed versions of these?

    thanks - dave

    ps - what we do is check for the registry entry and if it's not there, send them to http://www.windwardreports.com/office_hotfix.htm in our setup program. We are hoping that these hotfixes will get added to the Office update soon and then we will just point them to that.

    Also, is there a registry entry (not just a node) that is set by this? It's not clear wix can look for just a registry node.

    Wednesday, January 04, 2006 3:35 AM
  • One of our applications uses these fixes and we have been happily deploying them as boot strapped setup.exe pre-requistites for some time.

     

    However, we now need to allow our applications to be deployed using group policies which means that only msi files can be deployed.

     

    For 2 of these patch files this is file, however for the exe this poses a problem. Is there anyway of finding out if this exe contains an msi which I can extract? Or is there any other way of distributing this using group policies?

     

    Thanks

    Mark

    Wednesday, July 16, 2008 10:37 AM
  • OK, I've worked out how to extract the files from the .exe (using /x), but the resulting file is a .msp file. Can anyone advise me on the best way to deploy this using group policies as I think this only support .msi files?

    Wednesday, July 16, 2008 10:58 AM
  • Apparently it's impossible to deploy .MSP file using GPO. The official approach is to apply the patch to the master msi and then redeploy.

     

    Unfortunatly it is not realistic for all of our customers to re-deploy Office.

     

    So I am stuck. In summary:

    - Our app needs to apply the 3 files that form this fix

    - The 2 MSI files are not a problem, the office2003-kb907417sfxcab-ENU.exe containing the MSP file is a problem.

    - I could remove the exe from the prerequisities and add an msi custom action to execute it but i'm unsure if this has legal implications and it isn't a recommended approach. Also I dont think some customers would appreciate office patches being applied without them knowing.

     

    Maybe someone could tell me what is contained within this patch and I could manually add the changes into our installer?

     

     

     

     

    Wednesday, July 16, 2008 1:20 PM
  • Just to close this off, the lack of any solution to this problem which many developers have experienced has forced me to employ a nasty hack which will breaks msi guidelines.

     

    So if you get this problem then i'm afriad dont waste your time trying to do things properly - you'll need to explore nested installs.

    Monday, July 21, 2008 3:06 PM
  • Need a Merge Module (MSM) for one of the Microsoft's Extensibility.dll

    Hi,

    We are developing an Plug-in for MS Outlook 2003/2005 in VS 2005.  We are using the InstallShield 2008 StandAlone builder for creating an Installer for the same. 

    We need to install a particular extensibility.dll in the GAC of the target machine when the Plug-in is being installed.

    This extensibility.dll is actually a binary that is shipped as a fix mentioned in KB908002
    http://support.microsoft.com/default.aspx/kb/908002

    The KB908002 restricts the fix to be supported by the Microsoft Setup Project and we cannot seem to include this fix along with the Install Shield 2008 StandAlone builder. 

    If we have merge module (MSM) available for the extensibility.dll, the we could merge it with our MSI that is generated by InstallShield.

    Please see if we can open an incident with Microsoft in providing this Merge Module (MSM) for the extensibility.dll

    The version information for extensibility.dll is:

    Name: Extensibility
    Version: 7.0.3300.0
    Culture: Neutral
    Public Key Token: b03f5f7f11d50a3a
    Company Name: Microsoft Corporation

    Thanks


    Friday, November 28, 2008 4:57 AM