Quantcast
Channel: EPPlus Issue Tracker Rss Feed
Viewing all 2262 articles
Browse latest View live

Commented Unassigned: EPPlus corrupts files with shared formulas with error values [15560]

$
0
0
I open and save an xlsm file containing shared formulas having error values with EPPlus 4.1.0 like this:
```
var fi = new FileInfo("sharedFormulas.xlsm");
var package = new ExcelPackage(fi);
package.Save();
```
After saving the package, Excel couldn't open the file. It looks like the cells aren't marked as error typed.
The formulas contain user defined functions, but they don't seem to be the problem.
I attach the file before saving with EPPlus.
Comments: Fixed in changeset 33392c36678d

Edited Unassigned: Cell Union Operator Selection (commas) Bug in ExcelRange [15561]

$
0
0
I think someone uncovered a bug with the iterator of ExcelRange:

http://stackoverflow.com/questions/40870194/epplus-chartpie-barchart-selectedb2-b36-b38-etc-excel-cells/40876125#40876125

I came up with this unit test which will show the problem in an worksheet:

```
[TestMethod]
public void Chart_From_Cell_Union_Selector_Bug_Test()
{
var existingFile = new FileInfo(@"c:\temp\Chart_From_Cell_Union_Selector_Bug_Test.xlsx");
if (existingFile.Exists)
existingFile.Delete();

using (var pck = new ExcelPackage(existingFile))
{
var myWorkSheet = pck.Workbook.Worksheets.Add("Content");
var ExcelWorksheet = pck.Workbook.Worksheets.Add("Chart");

//Some data
myWorkSheet.Cells["A1"].Value = "A";
myWorkSheet.Cells["A2"].Value = 100; myWorkSheet.Cells["A3"].Value = 400; myWorkSheet.Cells["A4"].Value = 200; myWorkSheet.Cells["A5"].Value = 300; myWorkSheet.Cells["A6"].Value = 600; myWorkSheet.Cells["A7"].Value = 500;
myWorkSheet.Cells["B1"].Value = "B";
myWorkSheet.Cells["B2"].Value = 300; myWorkSheet.Cells["B3"].Value = 200; myWorkSheet.Cells["B4"].Value = 1000; myWorkSheet.Cells["B5"].Value = 600; myWorkSheet.Cells["B6"].Value = 500; myWorkSheet.Cells["B7"].Value = 200;

//Pie chart shows with EXTRA B2 entry due to problem with ExcelRange Enumerator
ExcelRange values = myWorkSheet.Cells["B2,B4,B6"]; //when the iterator is evaluated it will return the first cell twice: "B2,B2,B4,B6"
ExcelRange xvalues = myWorkSheet.Cells["A2,A4,A6"]; //when the iterator is evaluated it will return the first cell twice: "A2,A2,A4,A6"
var chartBug = ExcelWorksheet.Drawings.AddChart("Chart BAD", eChartType.Pie);
chartBug.Series.Add(values, xvalues);
chartBug.Title.Text = "Using ExcelRange";

//Pie chart shows correctly when using string addresses and avoiding ExcelRange
var chartGood = ExcelWorksheet.Drawings.AddChart("Chart GOOD", eChartType.Pie);
chartGood.SetPosition(10, 0, 0, 0);
chartGood.Series.Add("Content!B2,Content!B4,Content!B6", "Content!A2,Content!A4,Content!A6");
chartGood.Title.Text = "Using String References";

pck.Save();
}
}
```
And the output:

![Image](https://i.stack.imgur.com/ycRKA.png)

Seems what when the iterator is evaluated it include the first cell TWICE. You can see this in code if you inspect the ExcelRange object Results view.

Ernie

Commented Unassigned: Cell Union Operator Selection (commas) Bug in ExcelRange [15561]

$
0
0
I think someone uncovered a bug with the iterator of ExcelRange:

http://stackoverflow.com/questions/40870194/epplus-chartpie-barchart-selectedb2-b36-b38-etc-excel-cells/40876125#40876125

I came up with this unit test which will show the problem in an worksheet:

```
[TestMethod]
public void Chart_From_Cell_Union_Selector_Bug_Test()
{
var existingFile = new FileInfo(@"c:\temp\Chart_From_Cell_Union_Selector_Bug_Test.xlsx");
if (existingFile.Exists)
existingFile.Delete();

using (var pck = new ExcelPackage(existingFile))
{
var myWorkSheet = pck.Workbook.Worksheets.Add("Content");
var ExcelWorksheet = pck.Workbook.Worksheets.Add("Chart");

//Some data
myWorkSheet.Cells["A1"].Value = "A";
myWorkSheet.Cells["A2"].Value = 100; myWorkSheet.Cells["A3"].Value = 400; myWorkSheet.Cells["A4"].Value = 200; myWorkSheet.Cells["A5"].Value = 300; myWorkSheet.Cells["A6"].Value = 600; myWorkSheet.Cells["A7"].Value = 500;
myWorkSheet.Cells["B1"].Value = "B";
myWorkSheet.Cells["B2"].Value = 300; myWorkSheet.Cells["B3"].Value = 200; myWorkSheet.Cells["B4"].Value = 1000; myWorkSheet.Cells["B5"].Value = 600; myWorkSheet.Cells["B6"].Value = 500; myWorkSheet.Cells["B7"].Value = 200;

//Pie chart shows with EXTRA B2 entry due to problem with ExcelRange Enumerator
ExcelRange values = myWorkSheet.Cells["B2,B4,B6"]; //when the iterator is evaluated it will return the first cell twice: "B2,B2,B4,B6"
ExcelRange xvalues = myWorkSheet.Cells["A2,A4,A6"]; //when the iterator is evaluated it will return the first cell twice: "A2,A2,A4,A6"
var chartBug = ExcelWorksheet.Drawings.AddChart("Chart BAD", eChartType.Pie);
chartBug.Series.Add(values, xvalues);
chartBug.Title.Text = "Using ExcelRange";

//Pie chart shows correctly when using string addresses and avoiding ExcelRange
var chartGood = ExcelWorksheet.Drawings.AddChart("Chart GOOD", eChartType.Pie);
chartGood.SetPosition(10, 0, 0, 0);
chartGood.Series.Add("Content!B2,Content!B4,Content!B6", "Content!A2,Content!A4,Content!A6");
chartGood.Title.Text = "Using String References";

pck.Save();
}
}
```
And the output:

![Image](https://i.stack.imgur.com/ycRKA.png)

Seems what when the iterator is evaluated it include the first cell TWICE. You can see this in code if you inspect the ExcelRange object Results view.

Ernie

Comments: Fixed in changeset 33392c36678d

Edited Unassigned: Column border quantum coupling [15562]

$
0
0
Downgrading to v. 4.0.3 fixed this issue for me.

Expected result:
- first two rows are bolded
- columns 8, 10, 12 and 14 have dotted right border

Actual result:
- all columns up to column 14 have dotted right border for the first two rows. There is some coupling between Row() and Column() accessors?

```
// TEST
var w = excel.Worksheets.Add("test");
w.Row(1).Style.Font.Bold = true;
w.Row(2).Style.Font.Bold = true;

for (var i = 0; i < 4; i++)
{
w.Column(8 + 2*i).Style.Border.Right.Style = ExcelBorderStyle.Dotted;
}
```

Commented Unassigned: Column border quantum coupling [15562]

$
0
0
Downgrading to v. 4.0.3 fixed this issue for me.

Expected result:
- first two rows are bolded
- columns 8, 10, 12 and 14 have dotted right border

Actual result:
- all columns up to column 14 have dotted right border for the first two rows. There is some coupling between Row() and Column() accessors?

```
// TEST
var w = excel.Worksheets.Add("test");
w.Row(1).Style.Font.Bold = true;
w.Row(2).Style.Font.Bold = true;

for (var i = 0; i < 4; i++)
{
w.Column(8 + 2*i).Style.Border.Right.Style = ExcelBorderStyle.Dotted;
}
```
Comments: Fixed in changeset 33392c36678d

Edited Unassigned: column border quantum coupling [15563]

$
0
0
Downgrading to v 4.0.3 fixed this issue.

Code to reproduce below.

Expected result:
- First two rows are bolded
- Columns 8, 10, 12 and 14 get a dotted right border style

Actual result:
- Every column up to 14 get dotted right border for the first two rows. I'd guess there is some reference that is not dropped correctly between Row() and Column() accessors.

```
// TEST
var w = excel.Worksheets.Add("test");
w.Row(1).Style.Font.Bold = true;
w.Row(2).Style.Font.Bold = true;

for (var i = 0; i < 4; i++)
{
w.Column(8 + 2*i).Style.Border.Right.Style = ExcelBorderStyle.Dotted;
}
```

Commented Unassigned: column border quantum coupling [15563]

$
0
0
Downgrading to v 4.0.3 fixed this issue.

Code to reproduce below.

Expected result:
- First two rows are bolded
- Columns 8, 10, 12 and 14 get a dotted right border style

Actual result:
- Every column up to 14 get dotted right border for the first two rows. I'd guess there is some reference that is not dropped correctly between Row() and Column() accessors.

```
// TEST
var w = excel.Worksheets.Add("test");
w.Row(1).Style.Font.Bold = true;
w.Row(2).Style.Font.Bold = true;

for (var i = 0; i < 4; i++)
{
w.Column(8 + 2*i).Style.Border.Right.Style = ExcelBorderStyle.Dotted;
}
```
Comments: Fixed in changeset 33392c36678d

Edited Unassigned: worksheet.InsertRow >1024 bug [15564]

$
0
0
worksheet.InsertRow(4, 1025, 3);
The formula recorded on line 1026(or 1027) moves to 1025 rows
If insert less than or equal to 1024 records will not be such a bug.

Commented Unassigned: worksheet.InsertRow >1024 bug [15564]

$
0
0
worksheet.InsertRow(4, 1025, 3);
The formula recorded on line 1026(or 1027) moves to 1025 rows
If insert less than or equal to 1024 records will not be such a bug.
Comments: Fixed in changeset 33392c36678d

Edited Unassigned: Excel crashes after Open and save as [15566]

$
0
0
after this simple piece of code the excel to load this file.

```
[TestClass]
public class UnitTest1
{

private string TemplateFileName = @".\templates\TestWithPivotTablePointingToExcelTableForData.xlsx";
private string ExportFileName = @".\templates\TestWithPivotTablePointingToExcelTableForData_Export.xlsx";

[TestMethod]
public void TestWithPivotTablePointingToExcelTableForData()
{
using (ExcelPackage excelpackage = new ExcelPackage(new FileInfo(TemplateFileName), true))
{
excelpackage.SaveAs(new FileInfo(ExportFileName));
}

}
}
```

as far as i can tell it occures when there is a pivottable in the sheet which points to an exceltable as datasource.

In the attachments i've added an example file.

excel error
Faulting application name: EXCEL.EXE, version: 16.0.4456.1003, time stamp: 0x58139d4f
Faulting module name: EXCEL.EXE, version: 16.0.4456.1003, time stamp: 0x58139d4f
Exception code: 0xc0000005
Fault offset: 0x01134c41
Faulting process id: 0x3184
Faulting application start time: 0x01d2507cb589c304
Faulting application path: C:\Program Files (x86)\Microsoft Office\Office16\EXCEL.EXE
Faulting module path: C:\Program Files (x86)\Microsoft Office\Office16\EXCEL.EXE
Report Id: f3cbc25f-bc6f-11e6-82c7-90e6ba1a467a
Faulting package full name:
Faulting package-relative application ID:

Commented Unassigned: Excel crashes after Open and save as [15566]

$
0
0
after this simple piece of code the excel to load this file.

```
[TestClass]
public class UnitTest1
{

private string TemplateFileName = @".\templates\TestWithPivotTablePointingToExcelTableForData.xlsx";
private string ExportFileName = @".\templates\TestWithPivotTablePointingToExcelTableForData_Export.xlsx";

[TestMethod]
public void TestWithPivotTablePointingToExcelTableForData()
{
using (ExcelPackage excelpackage = new ExcelPackage(new FileInfo(TemplateFileName), true))
{
excelpackage.SaveAs(new FileInfo(ExportFileName));
}

}
}
```

as far as i can tell it occures when there is a pivottable in the sheet which points to an exceltable as datasource.

In the attachments i've added an example file.

excel error
Faulting application name: EXCEL.EXE, version: 16.0.4456.1003, time stamp: 0x58139d4f
Faulting module name: EXCEL.EXE, version: 16.0.4456.1003, time stamp: 0x58139d4f
Exception code: 0xc0000005
Fault offset: 0x01134c41
Faulting process id: 0x3184
Faulting application start time: 0x01d2507cb589c304
Faulting application path: C:\Program Files (x86)\Microsoft Office\Office16\EXCEL.EXE
Faulting module path: C:\Program Files (x86)\Microsoft Office\Office16\EXCEL.EXE
Report Id: f3cbc25f-bc6f-11e6-82c7-90e6ba1a467a
Faulting package full name:
Faulting package-relative application ID:
Comments: Fixed in changeset 33392c36678d

Edited Unassigned: Adding VBA to a file can lead to a corrupted file (sheetPr) [15547]

$
0
0
When loading a file and then using this line:
```
package.Workbook.CreateVBAProject();
```
the file can get corrupted. This happens because <sheetPr codeName="" ...> is changed or set incorrectly.
I noticed that the "codeName" should be at max 22 chars long, but there are examples where longer names do work fine.
Examples:
```
<sheetPr codeName="This is a longer name abC" is ok and 25 characters long
<sheetPr codeName="1-This is a longer name a" is not ok and 25 characters long
<sheetPr codeName="1-This is a longer name" is not ok and 23 characters long
<sheetPr codeName="1-This is a longer nam" is ok and 22 characters long
```

Currently I have two workarounds which are not good.
1) Get "codeName" of all sheets, use the "CreateVBAProject" function and restore the "codeName"s
2) Use the "CreateVBAProject" function and trim the "codeName"s to 22 chars.

Best fix would be to not update the "codeName" if it exists or use at max 22 characters as the above examples show valid sheet names.
Or even better find out why some "codeName"s are ok and others not.

Commented Unassigned: Adding VBA to a file can lead to a corrupted file (sheetPr) [15547]

$
0
0
When loading a file and then using this line:
```
package.Workbook.CreateVBAProject();
```
the file can get corrupted. This happens because <sheetPr codeName="" ...> is changed or set incorrectly.
I noticed that the "codeName" should be at max 22 chars long, but there are examples where longer names do work fine.
Examples:
```
<sheetPr codeName="This is a longer name abC" is ok and 25 characters long
<sheetPr codeName="1-This is a longer name a" is not ok and 25 characters long
<sheetPr codeName="1-This is a longer name" is not ok and 23 characters long
<sheetPr codeName="1-This is a longer nam" is ok and 22 characters long
```

Currently I have two workarounds which are not good.
1) Get "codeName" of all sheets, use the "CreateVBAProject" function and restore the "codeName"s
2) Use the "CreateVBAProject" function and trim the "codeName"s to 22 chars.

Best fix would be to not update the "codeName" if it exists or use at max 22 characters as the above examples show valid sheet names.
Or even better find out why some "codeName"s are ok and others not.
Comments: Fixed in changeset 33392c36678d

Edited Unassigned: Comments.Remove on a cell breaks comments in same column [15549]

$
0
0
Version: EPPlus 4.1

After removing a comment from a cell, further accesses to comments on other cells of the same column get unexpected results: either cell.Comment returns null even if a comment is actually present, or ws.Comments.Remove(cell.Comment) throws "Comment does not exist in the worksheet" exception.

Unit tests for bug reproduction (using attached in.xslx):

```
[TestMethod]
public void BugCommentNullAfterRemove() {

string xls = "in.xlsx";

ExcelPackage theExcel = new ExcelPackage(new FileInfo(xls), true);

ExcelRangeBase cell;
ExcelComment cmnt;
ExcelWorksheet ws = theExcel.Workbook.Worksheets[1];

foreach (string addr in "B4 B11".Split(' ')) {
cell = ws.Cells[addr];
cmnt = cell.Comment;

Assert.IsNotNull(cmnt, "Comment in " + addr + " expected not null ");
ws.Comments.Remove(cmnt);
}

}

[TestMethod]
public void BugCommentExceptionOnRemove() {

string xls = "in.xlsx";

ExcelPackage theExcel = new ExcelPackage(new FileInfo(xls), true);

ExcelRangeBase cell;
ExcelComment cmnt;
ExcelWorksheet ws = theExcel.Workbook.Worksheets[1];

foreach (string addr in "B4 B16".Split(' ')) {
cell = ws.Cells[addr];
cmnt = cell.Comment;

try {
ws.Comments.Remove(cmnt);
} catch (Exception ex) {
Assert.Fail("Exception while removing comment at " + addr + ": " + ex.Message);
}
}

}

```
After initial investigation, the problem seems to be in CellStore<T>.Delete, because the content of _commentsStore gets corrupted immediately after the first call to ExcelCommentCollection.Remove.

Same code referencing EPPlus 4.0.5 works fine.

Commented Unassigned: Comments.Remove on a cell breaks comments in same column [15549]

$
0
0
Version: EPPlus 4.1

After removing a comment from a cell, further accesses to comments on other cells of the same column get unexpected results: either cell.Comment returns null even if a comment is actually present, or ws.Comments.Remove(cell.Comment) throws "Comment does not exist in the worksheet" exception.

Unit tests for bug reproduction (using attached in.xslx):

```
[TestMethod]
public void BugCommentNullAfterRemove() {

string xls = "in.xlsx";

ExcelPackage theExcel = new ExcelPackage(new FileInfo(xls), true);

ExcelRangeBase cell;
ExcelComment cmnt;
ExcelWorksheet ws = theExcel.Workbook.Worksheets[1];

foreach (string addr in "B4 B11".Split(' ')) {
cell = ws.Cells[addr];
cmnt = cell.Comment;

Assert.IsNotNull(cmnt, "Comment in " + addr + " expected not null ");
ws.Comments.Remove(cmnt);
}

}

[TestMethod]
public void BugCommentExceptionOnRemove() {

string xls = "in.xlsx";

ExcelPackage theExcel = new ExcelPackage(new FileInfo(xls), true);

ExcelRangeBase cell;
ExcelComment cmnt;
ExcelWorksheet ws = theExcel.Workbook.Worksheets[1];

foreach (string addr in "B4 B16".Split(' ')) {
cell = ws.Cells[addr];
cmnt = cell.Comment;

try {
ws.Comments.Remove(cmnt);
} catch (Exception ex) {
Assert.Fail("Exception while removing comment at " + addr + ": " + ex.Message);
}
}

}

```
After initial investigation, the problem seems to be in CellStore<T>.Delete, because the content of _commentsStore gets corrupted immediately after the first call to ExcelCommentCollection.Remove.

Same code referencing EPPlus 4.0.5 works fine.

Comments: Fixed in changeset 33392c36678d

Commented Unassigned: EPPlus Breaks Table Formulas [15538]

$
0
0
I have an xlsx file with two worksheets. The first worksheet has a table that is populated by the second worksheet. With just opening it as an EPPlus package and saving the package, the table is broken and each field in a column references the same cell. Looking at the underlying xml files, it appears that worksheet1.xml has the bad formulas associated with it, while table1.xml has the correct ones.

For example, column A, row 1 is ='Sheet2'!A1 and column A, row 2 = 'Sheet2'A2. After opening and saving it in EPPlus, we then have both cells in column A are ='Sheet2'A2. I have attached a before and after of the workbook. The C# code is below:

```
namespace WorkbookManager
{
class Program
{
static void Main(string[] args)
{
var options = new Options();
if (Parser.Default.ParseArguments(args, options))
{
var file = new FileInfo(@"C:\Temp\TableIssue-BeforeEPPlus.xlsx");

using (var excelPackage = new ExcelPackage(file))
{
excelPackage.SaveAs(new FileInfo(@"C:\tmp\TableIssue-AfterEPPlus.xlsx"));
}
}
}
}
}

```
Comments: I am also experiencing this issue, is there a workaround known?

Created Unassigned: Non-Contiguous Named Ranges Grow [15576]

$
0
0
Given an Excel spreadsheet with a named region that is non-contiguous, =Sheet1!$D$16:$D$30,Sheet1!$L$16:$L$25, if I open the spreadsheet with the .NET library, then save the spreadsheet with the .NET Library, and then open the spreadsheet in Excel the non-contiguous named regions will duplicate the first entry resulting in a named region that now is =Sheet1!$D$16:$D$30,Sheet1!$D$16:$D$30,Sheet1!$L$16:$L$25.

The duplication of the first entry in the non-contiguous named range occurs during the load phase of the .NET library. If I open it in the debugger and look at the collection of named ranges, it already has duplicated the first entry. Every subsequent open and save in .NET results in an additional first entry for each non-contiguous named region.

Commented Unassigned: Getting a cellvalue in workbook slowing the performance in result [15557]

$
0
0
Hi ,
dll version : 4.0.5
I am using countifs formula then calculate function and after that when trying to get the cell value like ( String val22 = (String)SummarysheetModel.Cells[k, 201, k, 201].Value.ToString(); ) , system getting slow at debugging and release mode.

I have lots of entries in Excel worksheet and want to calculate each cell and show in new worksheet.

Please let me know if this is a correct to get the cell value.
sheet["B3"].Formula = "COUNTIFS(Data!V:V,\"CODE\",Data!AL:AL,\"MODEL\")";
sheet.Cells[k, 201, k, 201].Calculate();
String val22 = (String)sheet.Cells[k, 201, k, 201].Value.ToString();
Comments: If you have a very large number of cells calculation could be slow. You could attach a logger to the FormulaParserManager as described here: https://epplus.codeplex.com/wikipage?title=About%20Formula%20calculation&referringTitle=Documentation And then share here how many cells that was calculated in your workbook.

Commented Unassigned: EPPlus Breaks Table Formulas [15538]

$
0
0
I have an xlsx file with two worksheets. The first worksheet has a table that is populated by the second worksheet. With just opening it as an EPPlus package and saving the package, the table is broken and each field in a column references the same cell. Looking at the underlying xml files, it appears that worksheet1.xml has the bad formulas associated with it, while table1.xml has the correct ones.

For example, column A, row 1 is ='Sheet2'!A1 and column A, row 2 = 'Sheet2'A2. After opening and saving it in EPPlus, we then have both cells in column A are ='Sheet2'A2. I have attached a before and after of the workbook. The C# code is below:

```
namespace WorkbookManager
{
class Program
{
static void Main(string[] args)
{
var options = new Options();
if (Parser.Default.ParseArguments(args, options))
{
var file = new FileInfo(@"C:\Temp\TableIssue-BeforeEPPlus.xlsx");

using (var excelPackage = new ExcelPackage(file))
{
excelPackage.SaveAs(new FileInfo(@"C:\tmp\TableIssue-AfterEPPlus.xlsx"));
}
}
}
}
}

```
Comments: This is affecting me as well. I don't mind some of the other bugs that cause issues when trying to manipulate advanced worksheet content - but this bug makes it so we cannot even make simple changes if the file contains tables with complex formulas.

Created Unassigned: v4.1 - We found a problem with some content [15577]

$
0
0


Hi,

I am getting that error message using the latest version 4.1 - works find on 4.0.5 but I need some of the new
features on the latest version like InsertColumn which copies comments, and notes etc...

error message
"We found a problem with some content in " when opening the file, after its stream as file.

This occurs when using GetAsByteArray()

I seen some examples like

Response.Clear();
Response.ClearHeaders();
Response.ContentType = "application/vnd.openxmlformats-officedocument.spreadsheetml.sheet";
Response.AppendHeader("Content-Disposition", string.Format("attachment;filename={0}", fileName));
Response.BinaryWrite(output);
Response.Flush();
Response.End();

and

const string contentType = "application/vnd.openxmlformats-officedocument.spreadsheetml.sheet";
return File(output, contentType, fileName);

but neither is working .





Viewing all 2262 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>