2
votes

My client recently migrated from 32-bit Excel 2016 to 64-bit Excel under Office 365 and retained 32-bit MS Project Standard 2010.

I have VBA code native to MS Project Standard 2010 which manipulates the Excel 2016 Application by early binding via the Excel 16.0 Object Library reference. Following migration of Excel to the Office365 64-bit version the library reference to it (in MS Project Standard 2010) is no longer available. It is not MISSING it is just not available in the list. It won't even load by GUID. I don't have admin rights and can't inspect or edit the registry. My IT support explained that the issue is probably because we are mixing 32-bit and 64-bit applications.

I have worked round the issue by converting code from Early-binding to Late-binding. I probably didn't catch everything (I have created a very lot of code in a very lot of application tools) and my concern is that some feature of my code that has not been converted correctly may not be discovered for some time.

My question is, should the Project 2010 application (Project 14.0) be able to make reference to the 64-bit Excel 16 under Office365 Object Library? If so, what should my IT support guy be looking at to fix the problem please?

If the answer really is no I will just have to stick with the late-binding and do some extensive testing.

1
Thanks PEH for adding the missing tags, I'm grateful.Malcolm Farrelle

1 Answers

1
votes

You cannot cross-reference between 64-bit libraries and 32-bit libraries in the same host. The host can only use libraries of the same bitness. Late-binding won't help you in this situation - it helps you where there are version mismatching but not when bitness don't match.

If you need to continue automation between Project and Excel, then you may need to have a 32-bit Excel installation, or consider installing 64-bit Project. There's the third option of shelling out to VBScript or Powershell and running it out of process but that can be a lot of work.