ClosedXML odd behavior
-
Exactly what I said.
-
Exactly what I said.
-
Nope, just offering unsolicited advice.
-
Nope, just offering unsolicited advice.
-
pkfox wrote:
NPOI
Funny, the author of the spreadsheets show as Apache POI. Related?
"Go forth into the source" - Neal Morse "Hope is contagious"
-
And you needn't bother respond either.
-
Firstly, I am not asking for help on a programming issue here. I'm mostly just trying to see if anyone else here is or has in the past been experiencing any problems using the ClosedXML .Net library to open/read Excel files. I have a simple process that has worked every day flawlessly for over 2 years, then out of the blue, started failing. :confused: Basically, ClosedXML was choking trying to open an Excel (*.xlsx) file. By choking, I mean it was an IO exception reporting that the file was corrupted. The weird thing is, I can copy that file to my desktop, open it in Excel, save it, copy it back to the server, and it works fine. :wtf: I am aware that a new version of OpenXML was released (right around the time that my process began failing???) with quite a few breaking changes. Coincidence?...I don't know yet. What's new in the Open XML SDK | Microsoft Learn[^] What I've tried: 0: Go to GitHub and get the latest ClosedXML libs. So this required a .net framework upgrade to 4.6+. No problem...compiles, go to open a spreadsheet and it complains about the XMLDocument version...go to GitHub, get that version and try again. It compiles fine, go to open a spreadsheet and now it whines about a netstandard library that it can't find. (sure this is an indication of inccompatibility) I tried different versions/combinations but the only way to get it working again was by reverting back to the original framework and original libraries. Back to square one. :doh: 1: Plead with the new IT guy responsible for scheduling that job to please change the format to CSV! :laugh: (the previous IT guy was on a power trip and refused to change it despite numerous requests) 2: Investigating the idea of simply extracting the sheet1.xml file from the archive and parsing it out. Then I wonder why if it was that easy, why there are so few solutions that mention this approach. It's possible that I'm looking at an extremely simple/limited structure (no formulas/formatting/etc.) in this particular file, but it looks feasible. In the event that #1 fails, this will probably be the next path of attack. 3: Install Excel on the customer's server. Ya know, they did give me an admin account so in theory, I can install anything required to get the job done. Also, I have an old Office 2007 disk around here that
kmoorevs wrote:
ClosedXML .Net library to open/read Excel files....I am aware that a new version of OpenXML was released
A commercial production application should be built using the following 1. Identify libraries used. 2. Copy those libraries to a source that is controlled by the company. 3. Those libraries should ONLY be updated manually. 4. When libraries are updated and a dependent application is rebuilt then all of the impacted functionality must be retested. Note that version identifiers should not be trusted. That is why step 2 is required. Version identifiers are nothing but a hint since nothing stops someone from updating a library and not changing the version number. If the above is not followed then it is quite possible to go for years without problems. Until the day something quite unexpected shows up.
-
Avoid Interop.
-
And you needn't bother respond either.
-
Well, there you go again.
