ClosedXML odd behavior
-
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
Never used it. What are you trying to do with it? Because I only needed to read it, I rolled my own XLSX reader.
-
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
I've used [NPOI](https://github.com/dotnetcore/NPOI) for years without any problems
In a closed society where everybody's guilty, the only crime is getting caught. In a world of thieves, the only final sin is stupidity. - Hunter S Thompson - RIP
-
Avoid Interop.
-
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:
.net framework upgrade to 4.6+ ... whines about a netstandard library that it can't find
Which version did you actually upgrade to? .NET Standard 2.0 sort-of works with 4.6.1+, but it has several issues. Microsoft recommend using at least 4.7.2: .NET Standard - .NET | Microsoft Learn[^]
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
kmoorevs wrote:
.net framework upgrade to 4.6+ ... whines about a netstandard library that it can't find
Which version did you actually upgrade to? .NET Standard 2.0 sort-of works with 4.6.1+, but it has several issues. Microsoft recommend using at least 4.7.2: .NET Standard - .NET | Microsoft Learn[^]
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
I've used [NPOI](https://github.com/dotnetcore/NPOI) for years without any problems
In a closed society where everybody's guilty, the only crime is getting caught. In a world of thieves, the only final sin is stupidity. - Hunter S Thompson - RIP
-
Richard Deeming wrote:
Which version did you actually upgrade to?
4.6.1 first then 4.7.2. Neither worked. Back to 4.5.2. :)
"Go forth into the source" - Neal Morse "Hope is contagious"
Any particular reason? 4.7.2 will make your life much easier when you want to reference a .NET Standard 2.0 library, and I don't recall seeing any breaking changes. I think the only thing that "broke" for me was an ambiguous reference error for a custom extension method I'd written, which had the same name as one they added to the BCL in 4.7.2. :)
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
Not saying it doesn't.
-
Not saying it doesn't.
-
No it isn't.
-
No it isn't.
-
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.
