我为一个团队工作，该团队目前专门在C/.NET中创建Windows桌面应用程序，该团队通过Office COM Interop与Microsoft Excel的本地用户实例进行交互。我目前负责指定一个新产品，但我被告知，除非应用程序可以在Mac和Windows上运行，否则项目将无法进行——也就是说，我们必须能够生成应用程序的Mac版本，该版本可以在OSX上本地安装，并与用户的Microsoft Excel for Mac实例的对象模型交互。

使用parallels、mono或wine运行应用程序(请参阅osx中的wine中的com interop，它从未得到响应)不是一个解决方案，因为应用程序的规范要求用户机器不以任何方式进行修改。我们只需假设用户有一个运行Excel的本地许可副本，并使用它……这是我们在Windows上一直做的事情，在Windows上它工作得很好。

我认为.NET核心是答案，但我找不到它明确表示我们可以(或将能够)从C访问Excel对象库的任何地方，当我们在Mac OSX上运行.NET核心时，安装了本地Excel for Mac副本。有人能告诉我这件事已经讨论过了，还是没有，告诉我如何才能从微软那里找到这件事，如果这在他们的.NET核心路线图中呢？

我收到了一些有用的反馈，来自一个同样措辞的问题，关于msdn。我也在.NET核心Github上发布了一个问题，但我认为已经很清楚这个问题的答案是什么，如下所示：

• .NET核心团队可能被说服添加对.NET核心类库中Office.Interop.Excel命名空间的访问权限，但仅限于Windows。
• 不能在OSX上对.NET核心执行此操作，因为环境是不适用于交换COM对象。
• 这只留下两个在Excel中操作对象的选项Mac，两者都已经存在：嵌入式VBA或JavaScript(Office外接程序)。
• Office加载项是面向Web驱动的数据的一个很好的新解决方案Excel中的对象-以及它的多平台性质非常棒-因此，享受从微软开发。但是，它并不打算是与COM管理复杂电子表格的性能相匹配，因为这不是它的焦点。
• 这意味着在Excel中没有管理对象的解决方案对于使用C的Mac，在Windows和Windows上似乎没有任何希望。

底线：非常受欢迎的.NET核心计划看起来像是一个修复，但遗憾的是，由于OSX的体系结构限制，它不是。

我之所以提交这个答案，是因为我认为我已经到了调查的最后一步了，但是如果有人认为上述任何一条都是错误的，请大喊！

谢谢。