We generate a report using Aspose.Cells and we need to enable Share Workbook editable by multiple users with enabled change tracking. Plus, it would be nice to be able to generate the first revision with “service” user name.
I found only workbook.Setting.Shared = true, but seems that does not have any effect. See attached screen shots for comparison.
Contents of XLSX with Excel after Share Workbook vs Apose with Settings.Shared=true: share_xl_vs_aspose.PNG (40.9 KB)
Please consider adding support for the feature. Full (with reading or/and modifying revisions) or at least partial (to generate XLSX with Shared enabled, with the 1st revision if required).
Please also provide us sample code and sample Excel file(s). Please also let us know what steps do we need to perform in Microsoft Excel to observe your requirements. It will help us understand your issue better and we will evaluate it and update you asap.
We are migrating legacy reports done using Excel COM API and need to implement equivalent save to:
xlWBNew.SaveAs(reportName + “.xlsb”, 50,
Type.Missing, Type.Missing,
Type.Missing, Type.Missing, XlSaveAsAccessMode.xlShared, ConflictOption.OverwriteChanges,
Type.Missing, Type.Missing,
Type.Missing, Type.Missing);
Please let me know if I need to file the request via paid support to expedite efforts.
We have logged your issue in our database for investigation. We will look into it and find, if your requirements are achievable using the current set of Aspose.Cells APIs. Or if they are feasible to be implemented. Once, there is some news for you, we will update you asap.
We have evaluated your issue further and we are afraid, we have no plan to support this feature now for performance. We will have to add many events to track all changes to support this feature so it is not feasible for us as well.
We don’t change tracking, we need to be able to produce XLSX with sharing enabled and change tracking enabled (just an empty first revision, a user with specified name, etc… i.e add couple of .xml files to XLSX). It should not effect performance…
Another, related question. If we decide to implement it ourselves, what are the facilities to customize /intercept/extends save in Aspose.Cells? This way we can avoid post-processing already saved by Aspose XLSX (this will definitely effect performance).
Thanks for your posting and considering Aspose APIs.
We have logged your comment in our database against this issue for product team consideration. Once, there is some news for you, we will let you know asap.
This is to inform you that we have marked this issue as resolved now. We will soon provide the fix after performing QA and including other enhancements and fixes.
What’s in the fix? Do I need only workbook.Setting.Shared = true; to produce a shared workbook?
And a meta issue. Can you publish hotfix versions to NUGET as well, maybe as a pre-release version, so it’s not picked up by random people, and only by users expecting the fix.
Otherwise we have keep hotfix versions like the recent 17.7.7 in our GIT repo (to have seamless build experience among our devs and CI server), and then it does not make sense to switch to a nuget dependency because later we probably (we get hotfixes all the time) have to switch to another hotfix version as a local dependency again (for more than few projects we have in the solution).
Please, communicate this issue to the dev team. I don’t see a reason why it should be a problem to publish hotfix versions (as pre-release versions) along with release versions.
We have logged your comment in our database against this issue for product team consideration and investigation. We will update you asap.
We promise only one release per month. Hot Fixes should not be given to users at all. But for user convenience that they don’t have to wait for one full month, we provide them. If you want to get Aspose.Cells via Nuget, then please wait for one full month.
By the way, Aspose.Cells for .NET 17.8 is now available via Nuget as well, so you can get it from Nuget.
However, next hot fixes like 17.8.1, 17.8.2, 17.8.3 etc. will be provided via forums and finally 17.9 will be provided via Nuget.
Your’re describing the current process. I’m well aware of it unfortunately, and point to the issue in it.
I’m not talking about releases. We are fine with monthly releases, with more thorough testing to avoid regressions and etc. I’m talking about means of delivery for hotfix versions we constantly depend on. It’s a separate issue. As I explained in my previous reply, switching back and forth between NUGET and local .DLL in multiple projects in our codebase is very manual and time consuming process. For NUGET dependencies we use PAKET (What is Paket?) which is a very convenient and efficient tool.
From my previous reply, publishing hotfix versions with pre-release versions makes general users to ignore them by default, and at the same time enables easy access for consumes that expect the fix version specifically. It is year 2017, not 2007 and downloading and committing binary dependencies to the repo is not acceptable anymore.
Just to add more context. In our organization we develop a general reporting solution base on Excel workbooks as templates for reports. This means that the engine built using Aspose.Cells deal with various Excel workbook provides by end users. This constantly reveals bugs/issues in the library. Some of them we report to Aspose, for some we choose to implement workarounds in our codebase as a faster/easier option.
I think it’s in the best interest of Aspose as a vendor to receive timely reports for as many issues as possible. That means that the whole feedback cycle should be straightforward and seamless, so less time we choose to skip it. That begs for supporting tool, like. NUGET to make it easier to incorporate provided fixes.
Another area would be on the reporting side. In many organizations Excel files contain private data. It’s our case most of the time, but should be common I expect. In case of an issue we have to clean the file from sensitive data, but in a way that preserve the issue. Only then we can report the file to Aspose. In most such cases the manipulation cannot be performed by Aspose.Cells itself. So we have to do it manually in Excel (very time consuming, especially for large files). I think it makes sense for Aspose to develop a tool that assists in this area. Bare in mind, the most difficult bugs to catch during testing (on Aspose side) are the ones we observe in a wild dealing with numerous (sometime very complex) files of our end-users. It’s a pity that in many cases there is not way to transfer such issues to Aspose.
Please communicate my concerns to the tech team leaders, or let me know if we need to report it through the paid support channel for it to be taken seriously.
