Thank You
Thank You
You can switch the date system in the spreadsheet itself. By default Excel for Windows uses the 1900 system, for Mac uses the 1904.
Good link on why and how you can change the date system: http://support.microsoft.com/kb/180162/en-us
Would be nice to have the library take care of this or to return the serial and the system so we can do the calculation.
I guess the dll that should be placed in net45 folder is Excel.4.5, not Excel.dll
I ran into this also. Had to grab the original binaries and put them in the /bin directory to handle it.
I've updated the package it should now correctly reference Excel.dll in net45 folder.
@edwinbleijenberg
Yes... That will solve the issue. But in a continuous integration environment, it's not possible and practical to always copy the right DLLs. I guess ExcelDataReader people will correct their nuget package ASAP
Hi @Ian1971,
Thank you very much. I'll check
The parameter is actually convertOADate and what it does is convert an OADate in an excel binary format to a datetime.
OADate does not apply to OpenXml dates as far as I know. The date is held in the xml as a date string not an OADate.
If you wanted to convert a DateTime to an OADate you would have to do that yourself.
When I open the .xlsx in WinZip and go to the sheet's xml I found the data stored as OADate.
I really don't know why this is happening.
The problem is conveting from string to DateTime. I just don't know how to convert it, because I don't know what format will be used (for example: in brazil date format is dd/mm/yyyy)
In https://exceldatareader.codeplex.com/SourceControl/latest#Excel/Excel.4.5.csproj and other csproj files you specify this version. Please remove this and rely on the nuget package.
ktarbet has uploaded a patch.
Description:
ExcelBinaryReader.AsDataSet(true); can cause NullReferenceException
The patch checks the value parameter for null before attempting conversion to DateTime.
-- Function Patched --
private object ExcelBinaryReader.tryConvertOADateTime(value,XFormat)
Sorry for troubling you guys.
This happened because when updating the package I've taken the original release binaries and just renamed the 4.5 assembly. I've thought that was enough. :-(
When installing the package NuGet should have added binding redirects to a app/web.config. They allow ExcelDataReader to correctly work with the 0.86 version of the SharpZipLib.
The descriptions states what versions are supported. You're version must not be supported.
"Lightweight and fast library written in C# for reading Microsoft Excel files __('97-2007__)"
Would it be better if I just update ExcelDataReader to use 0.86?
2vertigo093i
Yes, NuGet do this, but Excel Data Reader still use old version, which is in its folder
Ian1971
Yes, I think this will be better solution. I do this by myself for my project, all work fine.