Please note this is a copy of a question I am also asking on StackOverflow. If I get an answer there I will post it here as an update I work for a team that currently specializes in creating windows desktop (WPF) applications in C#/.NET that interwork with local user instances of Microsoft Excel via Office Interop. I am currently charged with specifying a new product but I’ve been told that the project will not go ahead unless the app can run on Mac as well as Windows – that is, we have to be able to produce a Mac version of the app that can install natively on OSX and interact with the object model of a user’s instance of Microsoft Excel for Mac. (Running the app in Parallels, Mono or Wine is not a solution because the spec for the app requires that the user machine is not modified in any way. We just have to assume the user has a licenced local copy of Excel running, and work with that which is what we have always done on Windows, where it works great). I think.NET Core is the answer but I can’t find anywhere where it says definitely that we can (or will be able to) access the Excel Object Library from C# when running.NET Core on Mac OSX with a local copy of Excel for Mac installed.
Can anybody point me please to where this has been discussed already, or it not, tell me how I can go about finding out from Microsoft if this is in their roadmap for.NET Core? Hi TechiMe, Based on, it seems it would not support. I suggest you add comments on this blog to see whether it will be supported. Not sure which is the best way, I suggest you try personal support. Or, I suggest you try in github. Best Regards, Edward MSDN Community Support Please remember to click 'Mark as Answer' the responses that resolved your issue, and to click 'Unmark as Answer' if not. This can be beneficial to other community members reading this thread.
Is MultiSelect broken in the mac version? If so, does anyone know of a workaround? There are differences in the way that the GetOpenFilename method is implemented in Microsoft Windows and in the Mac. The ButtonText parameter is only available for the Mac. Additionally, the FileFilter and MultiSelect parameters are not available for the Mac. 17-May-2018: Making PDF files with VBA page with new download. 15-Jan-2018: Update: Mail code for Excel 2016 for the Mac. 21-Nov-2017: Update: Mac Excel version and Mac Office language settings.
If you have any compliments or complaints to MSDN Support, feel free to contact. Hi TechniMe, Excel for Mac has limited support for add-ins - there is partial VBA support but otherwise neither the COM object model nor the native Excel C API is supported. Microsoft is actively developing the JavaScript APIs that work across the various platforms, including the web-based version of Excel. The most official response to this issue is the comment from Office Developer Team to a: ' Our focus is on enabling cross-platform solutions using modern web extensions. We’d like for the add-ins and UDF to work across multiple platforms including browser in a seamless fashion with minimal developer effort to make it functional across all platforms. We think Web platform using JavaScript is the best way to achieve this goal.' This means for integrating with Excel for Mac, you have two choices: Find a way to interact with a VBA add-in, or somehow use the JavaScript API.
I think you will find both options very frustrating. Nothing else related to COM or.NET is on the horizon. I would suggest you reconsider whether support for Excel on Mac is really a requirement, and perhaps do some market research. In my experience, 'real' Excel users use the 'real' Excel (i.e.
The desktop version on Windows). Two public channels for making suggestions are:.
Looking around there will give you some idea of the plans and responsiveness of the development teams.Govert - Free and easy.NET for Excel. Thanks to Edward and Govert for their answers on this. I have been following up with Microsoft in the ways that Edward suggested but this is only reinforcing the general conclusion of these posts, which is that Microsoft's attention is now 100% focussed on Office Addins. Which are a great solution for web-driven data objects but doesn't begin to take the place of COM manipulation for work on the spreadsheet itself. I think Govert's right that there's a trend for 'real' Excel users to use the 'real' Excel', which in my experience often includes using Excel for Windows on Parallels on OSX, the main motivation for which is that the Mac version of Excel is usually 2-3 years behind the Windows version.
However, Mac's share has been steadily growing and Mac Excel has been getting better so, whilst we could try and ignore the issue before, that's getting difficult now, in my opinion. Wiki says that 11% of all laptop web accesses (one way of measuring real market penetration) are from OSX, but Mac's share in Europe is higher than the world in general so it may be as high as 1 in 5 that side of the pond.
It's a big ask to tell all those Mac users to go out and buy Parallels and a second copy of Excel in order to use your solution. Unfortunately I think that's where we are and will remain, for any integrators for whom VBA or Javascript access doesn't hack it.
The very welcome.NET Core initiative looked like it was a fix, but sadly isn't. Thanks for your help on this guys.
Hi TechiMeI can’t find anywhere where it says definitely that we can (or will be able to) access the Excel Object Library from C# when running.NET Core on Mac OSX with a local copy of Excel for Mac installed In my option, Excel Object Library could not be used on Mac. As well known, Com is not supported or not very good support on Mac.
And Excel Object Library relay on Com.NET Core is light weight, and it might not support com. For developing Office for cross platform, I would suggest you try developing Office Add-ins. # Excel JavaScript API programming overview Best Regards, Edward MSDN Community Support Please remember to click 'Mark as Answer' the responses that resolved your issue, and to click 'Unmark as Answer' if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact. Hi Edward Many thanks for your reply. I was afraid that might be the case, but it seems like a big hole in the Excel offering on Mac if you won't ever be able to drive it in anything like the way you already can on Windows.
Just one thing, which might just be a mix of words, could you just clarify what you mean by ' Excel Object Library relay on Com (,Net Core) might not support com'? Are these two different uses of the word 'Com'? (I'd like to get the wording completely unambiguous because your answer is extremely important and I will be republishing it elsewhere with a link back to here). Thanks again. Sorry for unclear. For COM, you could refer. As you know, we need Microsoft.Office.Interop.Excel to develop Excel application on Windows.
NET Core is a platform, and could load. You could assume that if Microsoft.Office.Interop.Excel could not be used in Mac, how could.NET Core use it.
Best Regards, Edward MSDN Community Support Please remember to click 'Mark as Answer' the responses that resolved your issue, and to click 'Unmark as Answer' if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact. Hi Edward, thanks for getting back. Yes indeed, that is my question, I need to find out whether Microsoft have any intention of adding Microsoft.Office.Interop.Excel to.Net Core Class Library. For us it will be okay to develop the first version on Windows and then do the Mac port later, but we need to know now whether it is in Microsoft's plan to allow the use of Excel Interop on Mac, because if not the port will never be possible. Do you know what is the best way to contact Microsoft about this please?
I will be happy to follow up with them, but I have no idea about how to go about it. Many thanks in advance! Hi TechiMe, Based on, it seems it would not support. I suggest you add comments on this blog to see whether it will be supported. Not sure which is the best way, I suggest you try personal support. Or, I suggest you try in github. Best Regards, Edward MSDN Community Support Please remember to click 'Mark as Answer' the responses that resolved your issue, and to click 'Unmark as Answer' if not.
![Excel Excel](/uploads/1/2/5/6/125644241/406973999.jpg)
This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact. Hi TechniMe, Excel for Mac has limited support for add-ins - there is partial VBA support but otherwise neither the COM object model nor the native Excel C API is supported.
Microsoft is actively developing the JavaScript APIs that work across the various platforms, including the web-based version of Excel. The most official response to this issue is the comment from Office Developer Team to a: ' Our focus is on enabling cross-platform solutions using modern web extensions. We’d like for the add-ins and UDF to work across multiple platforms including browser in a seamless fashion with minimal developer effort to make it functional across all platforms. We think Web platform using JavaScript is the best way to achieve this goal.' This means for integrating with Excel for Mac, you have two choices: Find a way to interact with a VBA add-in, or somehow use the JavaScript API. I think you will find both options very frustrating.
Nothing else related to COM or.NET is on the horizon. I would suggest you reconsider whether support for Excel on Mac is really a requirement, and perhaps do some market research. In my experience, 'real' Excel users use the 'real' Excel (i.e. The desktop version on Windows). Two public channels for making suggestions are:. Looking around there will give you some idea of the plans and responsiveness of the development teams.Govert - Free and easy.NET for Excel.
Thanks to Edward and Govert for their answers on this. I have been following up with Microsoft in the ways that Edward suggested but this is only reinforcing the general conclusion of these posts, which is that Microsoft's attention is now 100% focussed on Office Addins. Which are a great solution for web-driven data objects but doesn't begin to take the place of COM manipulation for work on the spreadsheet itself. I think Govert's right that there's a trend for 'real' Excel users to use the 'real' Excel', which in my experience often includes using Excel for Windows on Parallels on OSX, the main motivation for which is that the Mac version of Excel is usually 2-3 years behind the Windows version. However, Mac's share has been steadily growing and Mac Excel has been getting better so, whilst we could try and ignore the issue before, that's getting difficult now, in my opinion. Wiki says that 11% of all laptop web accesses (one way of measuring real market penetration) are from OSX, but Mac's share in Europe is higher than the world in general so it may be as high as 1 in 5 that side of the pond.
It's a big ask to tell all those Mac users to go out and buy Parallels and a second copy of Excel in order to use your solution. Unfortunately I think that's where we are and will remain, for any integrators for whom VBA or Javascript access doesn't hack it.
The very welcome.NET Core initiative looked like it was a fix, but sadly isn't. Thanks for your help on this guys.