Enable users to detect if add-in is running in Excel 2019 or 365
See original GitHub issueMicrosoft decided not to bump the version number of Excel in Office 2019 and Office 365 and for this reason, the ExcelDnaUtil.ExcelVersion
returns 16
for Excel 2016 or 2019 or 365 and users cannot easily tell which version of Excel their add-in is running other than knowing it’s >= 2016
Excel2003 = 11 => Office 2003
Excel2007 = 12 => Office 2007
Excel2010 = 14 => Office 2010
Excel2013 = 15 => Office 2013
Excel2016 = 16 => Office 2016 or 2019 or 365
In terms of API, I think it makes sense to leave ExcelDnaUtil.ExcelVersion
as is, and introduce a new property in ExcelDnaUtil
e.g. ExcelVersionName
that returns a string with the Office version e.g. Excel 2013
, Excel 2019
, etc.
ps: This does not affect our MSBuild tasks because we only attempt to detect the version of Excel in order to find where EXCEL.EXE
is located, in order to determine the bitness, and the registry key continues to be the same as Excel 2016 for Excel 2019 & 365.
Issue Analytics
- State:
- Created 3 years ago
- Comments:6 (4 by maintainers)
This is the result of
FileVersionInfo.GetVersionInfo(Process.GetCurrentProcess().MainModule.FileName)
To be clear - my objection was not about adding a helper to get detailed version information, but about the fact the “Excel 2019” vs. “Office 365” is not a useful distinction. Ideally we’d want two sets of information, the version from the File -> Account screen showing the build, channel and install mode:
Version 2008 (Build 131202.20002 Click-to-Run)
and then also the About infoMicrosoft Excel for Microsoft 365 MSO (16.0.131202.20002) 32-bit
I guess one would have to trawl through the registry to find the relevant bits and pieces.
(And even then, this is not enough for feature detection like knowing whether the Dynamic Arrays of StockHisotory is supported in the running instance.)