Daniel,

for my taste the problem description still is a bit vague (not even clear if vfp calls Excel via COM or other way round as start, in- or out-of-process targeted, just method calls needed or GUI on COM-Exe implemented and what functionality is offered...) so I can give you only basic hints on what I would try to aim for:

As encountering 64bit Office will happen some time, I'd prepare by always working out-of-process.
Best way of data transfer (esp. for debug) is bulk via disk, _clipboard coming close for ease of coding, often even faster runtime
Controlling Office from vfp to be avoided if possible (exception was Outlook for bulk mails), as version changes in Office happen

Personally I'd stay away from subscription models - I'd go for licenses from the XP - 2010 area sold cheap if you need to give away "automated Office" as it lowers your version testing ***OR*** follow the example of one license per each version in a VM for each year if you need to test working with your vfp-COM exe from different Office versions installed on client machines you have no control over.


>As you caught I do not really need Office for in-house document management. The need is in direct relation with the support OLE-com functionnality within a VFP app.
>
>This has worked flawlessly over the last 20 years. But we are moving on, like most, and wish to reduce dependencies We will reduce the support for Excel via COM in the application that still rely on the MS office package in 2018 (via xlsgen) this year. But we intend to keep some sort OLE-based imports because our customers still use Excel quite heavily.
>
>I am trying to find the most economical way to support this Excel COM-basyed dependency. Well I reckon I'll purchase a couple of Office365 license for this year and possibly next year as well! Rent not buy. As for real estate, when you intend to relocate, renting possibly the best choice:-)