Using the version 4 Beta, I'm getting incorrect results when using the Calculate method on my worksheet. Below is my example Unit Test code to show the issue. This is the unit test error message, "Assert.AreEqual failed. Expected:<Doe, John>. Actual:<OfficeOpenXml.FormulaParsing.EpplusExcelDataProvider+RangeInfo, John>. " It's interesting how it handles John just fine but not Doe. I'd assume it's due to the order of the expression compilation.
I greatly appreciate the work put into this library. I wish I could figure this bug out myself but when stepping through the debugger I couldn't get my head around all that was going on. Thanks.
```
[TestMethod]
public void Calculation5()
{
var pck = new ExcelPackage();
var ws = pck.Workbook.Worksheets.Add("Calc1");
ws.Cells["A1"].Value = "John";
ws.Cells["B1"].Value = "Doe";
ws.Cells["C1"].Formula = "B1&\", \"&A1";
ws.Calculate();
Assert.AreEqual("Doe, John", ws.Cells["C1"].Value);
}
```
Well, turns out I was able to figure out what the issue was. If the formula started with an ExcelAddressExpression it was immediately converted to a StringExpression in the StringConcatStrategy.Compile method which shouldn't happen for an ExcelAddressExpression as the value it will return is OfficeOpenXml.FormulaParsing.EpplusExcelDataProvider+RangeInfo. The fix was just to change the line in the StringConcatStrategy.Compile method from
```
var newExp = ExpressionConverter.Instance.ToStringExpression(_expression);
```
to
```
var newExp = _expression is ExcelAddressExpression ? _expression : ExpressionConverter.Instance.ToStringExpression(_expression);
```
I greatly appreciate the work put into this library. I wish I could figure this bug out myself but when stepping through the debugger I couldn't get my head around all that was going on. Thanks.
```
[TestMethod]
public void Calculation5()
{
var pck = new ExcelPackage();
var ws = pck.Workbook.Worksheets.Add("Calc1");
ws.Cells["A1"].Value = "John";
ws.Cells["B1"].Value = "Doe";
ws.Cells["C1"].Formula = "B1&\", \"&A1";
ws.Calculate();
Assert.AreEqual("Doe, John", ws.Cells["C1"].Value);
}
```
Well, turns out I was able to figure out what the issue was. If the formula started with an ExcelAddressExpression it was immediately converted to a StringExpression in the StringConcatStrategy.Compile method which shouldn't happen for an ExcelAddressExpression as the value it will return is OfficeOpenXml.FormulaParsing.EpplusExcelDataProvider+RangeInfo. The fix was just to change the line in the StringConcatStrategy.Compile method from
```
var newExp = ExpressionConverter.Instance.ToStringExpression(_expression);
```
to
```
var newExp = _expression is ExcelAddressExpression ? _expression : ExpressionConverter.Instance.ToStringExpression(_expression);
```