Making sure this your product and installer will work on Windows XP SP2/SP3 x86 / x64, Vista x86 / x64 and Windows 7 x86 / x64 in conjunction with Office 2007 and Office 2010 can really take quite a bit of time even with the help of Hyper-V snapshots to make sure that you aren't missing any edge cases. You have prereqs with prereqs such as VSTO -> .NET 4.0 -> Windows Imaging Components -> MSI 3.1 in the case of Windows XP SP2. Microsoft doesn't keep it simple but thankfully InstallShield does a good job trying to keep up.
Somethings have improved as Office 2010 once again behaves like Office 2003 in allowing you to register AddIns in HKEY_LOCAL_MACHINE ( the hell that is Office 2007 is fodder for another blog post ) but Office 2010 adds a whole new wrinkle that makes me want to pull my hair out: Bitness Pain
Let's start with the easy bitness pain: VSTOR40_x86.exe vs VSTOR40_x64.exe. The VSTO AddIn has a run time dependency that's tied to the platform of Windows that you are running on. Still, since the setup.exe bootstrapper is handling VSTOR for me, this is a pretty easy problem to solve.
Now for the harder pain: Your AnyCPU VSTO AddIn has to be registered in HKEY_LOCAL_MACHINE but which hive? The 64bit or the 32bit?
If you picked 64bit you are probably wrong. If you said "use registry reflection you re probably wrong also since this was removed from Windows 7 and considering how much of a flop Vista was your user is probably running Windows 7.
See, it doesn't matter that you are running 64bit Windows, it matters if you are running 64bit Office! Now for the kicker, Microsoft has a complicated work flow for recommending if a user should install the x86 Office or the x64 Office. It basically boils down to Developers and Hard Core Excel Junkies with spreadsheets larger then 2GB should run x64 and the rest of the world should run x86. In fact, if you stick the disk in and run the setup.exe from the root you are very likely to get x86 Office 2010.
.gif)
So now you have this AnyCPU AddIn packaged up in MSI which doesn't officially support hybrid installs which means you have to have 2 downloads and hope your user is smart enough to know which one to download. Or you have to make 2 MSI's and wrap it with a bootstrapper .... something that InstallShield can't do at the moment.
Hmmm... what to do, what to do? I guess I could just punt and only support x86 Office. After all the vast vast majority of users will be using it. But Microsoft really wants to move the community forward and I really don't want to leave my customer taking even 1 support call trying to get their AddIn to work.
So I think I'm going to vote for a Hybrid install on this one. It's only 4 registry values that I need to write so I'm going to put my nose up in the air at Windows Installer and roll a custom action which fires only on 64 machines to write the values and remove them on uninstall.
If anyone at Microsoft is reading, and I know you are from my http logs, please, please try to do something to fix this. This single bitness limitation in MSI is just going to become more and more painful in my opinion.
PS- I'll probably never get back to the Office 2007 comment so here goes. 2007 only supported registering AddIns in HKEY_CURRENT_USER. There is a HotFix available along with a registry value to fix this and Microsoft blog articles say 'we fixed it' but here's the catch. We aren't allowed to redistribute it with our installers. We have to hope that end users have patched their machines via Microsoft Update. Well I didnt want my customer to have to get that support call either so I wrote an AppSearch that checks if Office12 MSO.DLL is present that it's atleast a certain version otherwise gate with a LaunchCondition.
2 comments:
Chris, good blog post. We just encountered something interesting last week where we saw 32-bit office 2010 installed on 64-bit windows drops some 64-bit office 2010 assemblies under program files. Haven't quite figured out why yet, other than noticing that they get used when you load an Office document inside of 64-bit IE.
I did have a question for you about authoring a solution that targets office 2007 & office 2010; have you determined a way to be version neutral, or are you specifically laying down registry keys with the office version in the path? (i.e. HKLM\Software\Microsoft\Office\12\User Settings)? I'd like to have to avoid cracking open an MSI just to change a 12 to a 14 (or a 14 to a 15 one day) and was wondering if you found a way.
In this case we are authoring an Outlook AddIn which writes to:
HKLM\SOFTWARE\Microsoft\Office\Outlook\AddIns\AddInName
So we already have version neutrality.
Post a Comment