Microsoft.Office.Interop.Excel failure


I have a problem that I can now only attribute to Oxygene. Back in Elements I had no issue, but by Elements I do.

I’m using Microsoft.Office.Interop.Excel to perform basic extract work. This has never been a problem, but after investigating some issues on user machines and thinking it was either OS versions, office DLL versions etc. I’ve now seen an error that has led me to think it is an Oxygene issue.

method MainForm.button1_Click(sender: System.Object; e: System.EventArgs);
var	lExcelApp		: Microsoft.Office.Interop.Excel.Application;
	lExcelApp := new Microsoft.Office.Interop.Excel.Application;
	lExcelApp.Visible := true;

Working on the same development machine, if I run an oxygene project with the above code, I get an error whilst executing the Open. If I run a C# project with the same code (below), the Open is successful.

 private void button1_Click(object sender, EventArgs e)
            var lExcelApp = new Microsoft.Office.Interop.Excel.Application();
            lExcelApp.Visible = true;


The error returned in HRESULT : 0x800A03EC


I don’t think the error code is that relevant. In the production code the initial error I encountered was on the Workbooks.Add (below). Until upgrading RemObjects versions, this had worked, but now it doesn’t. I managed to work around that by using the version of add that specified the xlWBTATemplate parameter, but that then just led on to the next error which was effectively the one you see above i.e. an error opening a workbook.

	lExcelApp := new Microsoft.Office.Interop.Excel.Application;
	lExcelApp.SheetsInNewWorkbook := 1;
	lDestWorkBook := lExcelApp.Workbooks.Add;
	//lDestWorkBook := lExcelApp.Workbooks.Add(XlWBATemplate.xlWBATWorksheet);

I have revisited the previous RemObjects version in an old development VM and the simple code above written in Oxygene continues to work. Given the old Elements version continues to work, my current one ( does not but a Microsoft C# version of the project does, them I’m left thinking this has to be a RemObjects bug ?

Out of curiosity, is this using a COMReference? If so, does changing the .targets import inside the project file to RemObjects.Elements.Echoes.Legacy.targets work around the issue?

Can you send us a small sample that illustrates the problem?


Hi Marc,

Getting a little late here, but here’s two sample projects - the working C# one and the non working Oxygene. The only code is as per above i.e. a couple of lines in the button click.Sample (131.1 KB) Sample C (246.3 KB)

Thanx. I’ll have someone look at that, but it probably won’t be until Monday, I’m afraid. as I myself am not on Windows, and most of the team’s already off into the weekend…

Maybe this problem:

Should these references maybe be Copy Local?

    <Reference Include="DevExpress.Data.v18.2" />
    <Reference Include="DevExpress.Printing.v18.2.Core" />
    <Reference Include="DevExpress.Sparkline.v18.2.Core" />
    <Reference Include="DevExpress.Utils.v18.2" />
    <Reference Include="DevExpress.XtraEditors.v18.2" />
    <Reference Include="Microsoft.Office.Interop.Excel" />


Sadly not. The open error was actually the second error I ran in to. The initial one was being generated just by adding a workbook

var	lExcelApp		: Microsoft.Office.Interop.Excel.Application := nil;
		lDestWorkBook	: Workbook := nil;
	lExcelApp := new Microsoft.Office.Interop.Excel.Application;
	lExcelApp.SheetsInNewWorkbook := 1;
	lDestWorkBook := lExcelApp.Workbooks.Add;
	//lDestWorkBook := lExcelApp.Workbooks.Add(XlWBATemplate.xlWBATWorksheet);

The code as it stands above worked fine in V8 of Elements, but in V10 it results in a failure on the WorkBooks.Add. I shouldn’t have to work around that, but I found the commented out line did get me past that i.e. adding a worksheet template. That then just led on to the open error. As these work fine in Microsoft C# on the same machine, I can’t help but think it is something resulting from the Elements version change.

I thought I had taken out the DevExpress dependancies, sorry… They were only in there as the textbox on the sample application was a DevExpress one and not a standard Microsoft one. I’ve removed them just for consistency, but as I’d expect, same result.

Although I don’t have definitive proof, I’m pretty sure this is presenting on user machines with more subtle consequences. For example, the calls into Excel don’t always fail, depending on the Excel version installed and possibly its bitness (32 / 64). I have at least a couple of examples where the live application is working against Excel 2010 (32 bit) but failing against Excel 2016 (32 bit). The user has had their IT install 64 bit Excel 2016 and that has worked around things (for 2 users). I’ve not been able to identify much commonality, and was having to accept the “install 64 bit Excel 2016” solution, but this issue I’ve raised here is much more definitive and repeatable. It feels like it will be intimately related.

Add the following line:
lDestWorkBook := lExcelApp.Workbooks.Add(Microsoft.Office.Interop.Excel.XlWBATemplate.xlWBATWorksheet);

Sorry Theo, maybe I wasn’t clear. It is much more basic problem. The .Add will fail without any parameters (it works in V8 and of course should continue to in V10). The commented out line .Add(XlWBATemplate.xlWBATWorksheet) will work in V10 (no reason it should do given the .Add fails, but I was looking for something to investigate a way forward). I shouldn’t have needed to try that workaround - the .Add by itself used to work and should now.That alone is enough to make me think there is an Elements issue. The follow on .Open error just compounds the issue and was where I stopped trying to work around things. I’m not a C# developer, but as per my sample application, the same code works in C# on the same development machine as the Oxygene failure.

No worries, but my point was that Microsoft.Office.Interop.Excel" /> probably needs to be copy-local?

I don’t believe it’s that relevant here. If there is a copy in the GAC then it will use that one. I have tried with all varieties of that DLL (and GAC / local) . Each version of Excel ships with different variant of course. Even within Excel the power query ships with its own version, so you can see a V15 and a V14 shipping with Excel 2016 for example.

Ok, then I don’t know. if it is GACed, CopyLocal won’t be needed, yes, but no idea what else could be causing the difference between C# or old Oxygene to latest, then. Someone from the Windows team will need to have a look on Monday, sorry.

Thanks, logged as bugs://83538

It’s been an issue on a number of users machines for months, but only came to light about 3 weeks ago. The specific issue here only came up last week and I was able to boil it down to these test cases. Not a problem to look at this next week (I’m about finished for the day as well)… Thanks.

I notice that the VC# project specifies a concrete version and hint path:

<Reference Include="Microsoft.Office.Interop.Excel, Version=, Culture=neutral, PublicKeyToken=71e9bce111e9429c, processorArchitecture=MSIL">
      <HintPath>C:\Program Files (x86)\Microsoft Visual Studio\Shared\Visual Studio Tools for Office\PIA\Office15\Microsoft.Office.Interop.Excel.dll</HintPath>

can you check the build log to see if the Oxygene project ends up refrencing the .dll from the same path as VC# does, or if int finds a different version? If it’s different — does adding a hint path to the version VC# links against solve the issue?

I’ll have to check tomorrow / Monday… Just to save me hunting around, where would I find the build log output ?!

1 Like

VS should have an Output pane, usually docked at the bottom. as part of the compile phase, at least Oxygene will list all referenced .dlls with full path (not sure if VC# does, you might need to increase the build log level in Tools|Options|Project & Solution).

Actually, I think the issue probably has the lack of EmbedInteropTypes, which (a) is missing bin the Oxygene project, but more importantly, I’m pretty sure EBuild does not currently support. I’ll log an issue to investigate.

Thanks, logged as bugs://83539