Hello.
We have a .NET application that is hosted in IIS.
We are using Aspose.Cells 18.3.0 to load a new Workbook object in .NET.
We have two problematic spreadsheets.
Excel Sheet #1 contains custom formatting of g, gg, and ggg.
Excel Sheet #2 contains formatting to use [$-ja-JP]XXXX (Microsoft Excel 2016)
Excel Sheet #1 always exhibits the issue.
Excel Sheet #2 only exhibits the issue when a non-date value is in the cell.
For either sheet, the issue only occurs if the machine’s current region is set to Japan.
The issue we are seeing is that upon loading the Workbook object with the above mentioned Excel sheets, our software’s System.Globalization.CultureInfo.CurrentCulture’s Date patterns, and calendar are modified to the current Reiwa era of Japan, and a Japanese calendar.
The only way we can get our software to revert is to reset IIS to restart our application.
Is this something that was addressed in a later version of Aspose, or something that you are already aware of and actively addressing?
This is causing issues with customers using our software, so it is urgent.
I have attached the problematic Excel sheets.
Our code uses the Workbook constructor that takes in a stream containing the Excel file’s data. The issue occurs immediately after this constructor is invoked and a Workbook object is returned to us.
Aspose.zip (13.3 KB)
@HylandRendering,
The workbook Locale.xlsx uses *DD/MM/YYYY format and Gengo.xls uses custom formatting g. Please review and mention formatting according to file name. Could you please share your code snippet (runnable) and screenshots of settings. We will reproduce the problem and provide our feedback after analysis.
Ah sorry, yes, Gengo.xls is using the g/gg/ggg formatting, and Locale.xlsx is using the Japanese date formatting.
The code we are using is the following. Does Aspose function differently if the program is hosted in IIS versus running as a standalone program? Thread.CurrentThread.CurrentCulture’s data is what is being modified after the Workbook constructor call.
using (FileStream fs = new FileStream("gengo.xls", FileMode.Open, FileAccess.Read))
{
var ff = Aspose.Cells.FileFormatUtil.DetectFileFormat(fs);
Workbook test = new Workbook(fs);
}
@HylandRendering,
I have tried to reproduce this issue but could not succeed. Could you please provide us a sample project (runnable) along with the detailed steps and images to reproduce the issue? It will help us to observe the issue here and provide assistance accordingly.
The issue seems to only occur when hitting our server side code that is hosted in IIS. This same code outside of IIS and our software doesn’t seem to produce the same issue.
Are there any special things to be aware of when using Aspose in software that is hosted in IIS, or is there a setting in Aspose that should be used to prevent the CurrentThread’s CurrentCulture from being modified?
Once this modification happens, it alters the behavior of our client.
@HylandRendering,
We have found the possibility of CurrentCulture modification but we need to look into it more. We have logged the issue in our database for investigation and for a fix. Once, we will have some news for you, we will update you in this topic.
This issue has been logged as
CELLSNET-46781 – System.Globalization.CultureInfo.CurrentCulture is modified
Great. Thank you.
We have also noticed that it happens with Excel 97-2003, but not later files like those generated with Office 2016, and the behavior is slightly different (but still incorrect) if you pass a culture into the Workbook constructor with LoadOptions
@HylandRendering,
Thank you for the feedback. We have recorded this information with the logged ticket for our reference.
Hello. I am just checking to see if we have any sort of status update on the research going into this issue.
This is a customer facing issue that we are experiencing, so I would like to be able to provide some status update back to them.
Thank you.
@HylandRendering,
Thank you for writing back to us. This issue is little complex hence taking time to accomplish. Although we are trying to get the progress, it may not be possible to share the details about the research for analyzing and resolving this issue. I will write back here immediately once any feedback or ETA is available for you.
We are sorry for the inconvenience caused in this regard.
@HylandRendering,
Please try our latest version/fix: Aspose.Cells for .NET v19.6.1 (attached)
The issue of CultureInfo being modified should have been fixed by the fix.
Let us know your feedback.
Aspose.Cells19.6.1 For .Net2_AuthenticodeSigned.Zip (4.9 MB)
Aspose.Cells19.6.1 For .Net4.0.Zip (4.9 MB)
Hello.
This seems to have resolved our issue.
Will there be a full update published for this new version, or will the provided DLL be all that is required? This will cause us to update from 18 to 19, so I believe we will also need to push this out with an updated license file so that the DLLs are not functioning in trial mode. The software version in question (an older version from us) is using Aspose 18 with the Aspose 18 license file.
Thank you.
@HylandRendering,
The provided DLLs pass through all the tests which are conducted during regular release. These can be used in the production environment if your license is working with these DLLs. Regarding the regular release, it will be released around the last week of July 2019.
The issues you have found earlier (filed as CELLSNET-46781) have been fixed in Aspose.Cells for .NET v19.7. This message was posted using BugNotificationTool from Downloads module by Amjad_Sahi
Hello,
Is this issue also something that can occur using other Aspose products such as Words or Slides?
Thank you!
@HylandRendering,
Yes, this can occur in other APIs too. If you are facing any problem then please post in appropriate category in our forum for further assistance.
Hello.
We may be seeing this issue due to other file formats but have not been able to track down a reliable case.
I could not find any mention of this “System.Globalization.CultureInfo.CurrentCulture” issue in any other release notes for other libraries.
Do we know if it was fixed in other libraries yet? You mentioned that it can occur in other libraries.
Thanks
@HylandRendering,
For the issue of cultureinfo being modified, different products have different requirements and usages of the cultureinfo. We don’t think it is possible for other products to use the same logic and give the same bug, even though we are not 100% sure of that. Still we need some details to check your issue with other file formats. For example, you have shared template files and code here for Aspose.Cells API. So please share some more details so that we can reproduce the problem and provide our feedback after analysis.
This is triggering data loss at our customer’s live environment, so we would like more information from you.
We are doing what we can to investigate. Right now, we are working on figuring out what is triggering the issue since current results seems to indicate that it is not the same situation as what is present in this support thread with the Excel formatting trigger.
You say that you are not 100% sure if other products use the same logic, but is that something you can check? Also back in August of last year, you confirmed that this can happen with other APIs. Which APIs? This can potentially help us in tracking down what the trigger is so we can work with you to identify and reproduce the problem.
Currently, because the trigger seems to be different, we are still working to track down the offending file as well as the functionality that is causing the issue with the customer, though the result of the problem itself is identical to the one we reported last year.
Also, since you have confirmed that this is a bug and back in August and, as stated above, you admit that this can happen with other APIs, is this being addressed at all? We ask since the way this bug manifests itself in our software is essentially changing the value of our metadata and causing the original data to be lost which, needless to say, is a major issue with our customer.
If it has been addressed we would like information about that as well. This way we will have both the potential issues to see if it fits the current situation, and proof that it has been addressed in a specific release of the Aspose library.
While we continue to investigate on our end, we would appreciate assistance and information from your side as well to prevent further customer data loss and find the issue as soon as possible.
Thank you!
@HylandRendering,
Could you please provide the details of other APIs and explain bit more about the features you mainly work with, so that we can narrow down the scope your issue and provide our feedback accordingly.