Microsoft.Office.Interop.Excel failure

[mh (marc hoffman)]

Actually, we do support it. try setting the option on the reference in the project and see f that does the trick?

[RemObjectsSoftware (RemObjects)]

bugs://83539 got closed with status nochangereq.

[pthompson]

Hi Marc,

Just catching up with this today. The simple answer seems to be “no”… Here’s what I’ve found and done.

The csproj file for the C# contains the following - as per what you found:-

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

I copied that without change into the .elements project file for the Oxygene sample, replacing

<Reference Include="Microsoft.Office.Interop.Excel" />

That did not make a difference to the result.
I then tried the reverse i.e. replacing the more verbose C# reference to the simple version in Oxygene. The C# application continued to work without the hint.

I switched on detailed logging. Here is a detailed log for the C# application

Build Log C# .txt (325.5 KB)

Here is a failed detailed build log for the Oxygene application. The failure seems to be related to my trying to match the settings for the Excel DLL with that seen in C#. Some combination of “Strong Name”, “Ignore Version”, “Embed Interop Types” set to true seems to result in the Ebuild failure here. Resetting the options to false produces a successful build (but still showing the problem).

Build Log Elements (Fail).txt (41.1 KB)

Here are the properties for the C# and Oxygene Excel references respectively.

Anything useful from this ?

[mh (marc hoffman)]

I’m confused between:

@pthompson

I copied that without change into the .elements project file for the Oxygene sample, replacing

<Reference Include="Microsoft.Office.Interop.Excel" />

That did not make a difference to the result.

and

@pthompson

Here is a failed detailed build log for the Oxygene application.

So did setting EmbedInteropTypes make no difference, or does it make the build fail?

In either case, the build failure looks to be a compiler bug:

|1>||E: Internal error: System.ArgumentNullException: Value cannot be null.|
|1>||Parameter name: interfaceType|
|1>|| at Mono.Cecil.Mixin.CheckType(Object type, Argument argument)|
|1>|| at Mono.Cecil.InterfaceImplementation…ctor(TypeReference interfaceType)|

@pthompson

Anything useful from this ?

|1>|| at RemObjects.Oxygene.Code.Output.DotNet.TypeDefWrapper.AddInterfaceImpl(TypeWrapper at)|

can we get the/a complete test case for that?

All that matters is what’s in the project. What version of the reference causes the compiler IE?

[RemObjectsSoftware (RemObjects)]

Thanks, logged as bugs://83556

[mh (marc hoffman)]

Also, what change causes these errors to show?

1>		E:                   Indirectly used type "Microsoft.Office.Core.MsoFlipCmd" is defined in an unreferenced assembly (office, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c)

[pthompson]

Here’s the sample application showing the build error

Oxygene compiler error.zip (131.8 KB)

The only change from the initial application is one setting. This generates the compiler error :-

i.e. changing the Embed Interop Types to True
Changing the final two Ignoreoptions to true does not result in a compiler error - there I was trying to emulate the C# settings.

I think the above also clarifies the confusion ?

The only compiler failure seems to be the above. All other changes I tried resulted in a successful Oxygene build, but the same runtime issue. In C# changing the Reference to remove the hint did not make a difference i.e. it opened the Excel file successfully.

[mh (marc hoffman)]

Right, so what this boils down to is that EmbedInteropTypes needs to be enabled to fix your issue, but enabling that currently causes the compile rebuff that we’ll need to fix (bugs://83556).

[pthompson]

That is where my thinking was taking me, at least I was trying to narrow the gap between the working C# and failing Oxygene versions.

I also suspect this will fix my wider issue that has been out in the wild. Without holding you to it, would you tend to agree ?

@pthompson

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.

[pthompson]

One other thought. How does this fit with the same code working on Elements V8 ?

In my old environment :-

<Reference Include="Microsoft.Office.Interop.Excel">
      <HintPath>C:\Program Files (x86)\Microsoft Visual Studio 11.0\Visual Studio Tools for Office\PIA\Office14\Microsoft.Office.Interop.Excel.dll</HintPath>
      <Private>False</Private>
    </Reference>

This works. The key here looks to be that no Embed Interop Types is set still set to false. So will fixing the compiler bug in V10 be the answer ?

[mh (marc hoffman)]

@pthompson

One other thought. How does this fit with the same code working on Elements V8 ?

No idea. For all we know this is a totally separate bug the EmbedInteropTypes flag and needs to investigated on its own, but we won’t know until we can try adding EmbedInteropTypes

[ck (Carlo Kok)]

I’ve fixed the internal error but the real cause is this:

You need to also reference Office.dll.

[RemObjectsSoftware (RemObjects)]

bugs://83556 got closed with status fixed.

[mh (marc hoffman)]

@ck

You need to also reference Office.dll.

But only when EmbedInteropTypes is on? Why didn’t these error show with it off?

[ck (Carlo Kok)]

Because when embedding I copy the types over. Part of this is copying the signatures over.

[mh (marc hoffman)]

Paul,

I’ve uploaded a new build to your Personal Downloads folder, with Carlo’s fix for EmbedInyteropTypes. Please let me know if this addresses the original issue or if it persists even with that option on.

thanx!
marc

[pthompson]

Thanks Marc. I’ll try and take a look later this afternoon, but may be tomorrow…

[pthompson]

Still looks to be a problem, different HRESULT

With the Interop.Excel settings like this

I had to add references to Office and Vbe.Interop, the settings for which I initially left as default. This is how the build was when it gave the above HRESULT.

If I said Embed Interop Types true on the two additional references (office and vbe) then I got this from the build, at which point I stopped digging…

1>------ Build started: Project: WindowsApplication2, Configuration: Debug ------
1>C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\RemObjects Software\Elements\RemObjects.Elements.Echoes.targets(53,3): error E326: Indirectly used type “stdole.IPictureDisp” is defined in an unreferenced assembly (stdole, Version=7.0.3300.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a)
1>C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\RemObjects Software\Elements\RemObjects.Elements.Echoes.targets(53,3): error E0: Internal error: System.NullReferenceException: Object reference not set to an instance of an object.
1> at Mono.Cecil.ParameterDefinition.get_CustomAttributes()
1> at E.a(Object a, Object b, ImmutableArray1 c, String d) 1> at E.a(Object a, Object b, IGetAttributes c) 1> at E.G.a(IMethodInfo a) 1> at E.f(BaseType a) 1> at E.e(BaseType a) 1> at E.d(BaseType a) 1> at E.G.a(IMethodInfo a) 1> at E.f(BaseType a) 1> at E.e(BaseType a) 1> at E.d(BaseType a) 1> at E.G.a(IMethodInfo a) 1> at E.f(BaseType a) 1> at E.e(BaseType a) 1> at E.d(BaseType a) 1> at E.G.a(IMethodInfo a) 1> at E.f(BaseType a) 1> at E.e(BaseType a) 1> at E.d(BaseType a) 1> at E.f(BaseType a) 1> at E.e(BaseType a) 1> at E.d(BaseType a) 1> at E.G.a(IMethodInfo a) 1> at E.f(BaseType a) 1> at E.e(BaseType a) 1> at E.d(BaseType a) 1> at E.f(BaseType a) 1> at E.e(BaseType a) 1> at E.d(BaseType a) 1> at E.a(IMutableMethodImplementation a) 1> at RemObjects.Oxygene.Code.CombinedParsedType.ForAllMethods(Func2 action)
1> at E.b(IMutableParsedType a)
1> at E.g()
1> at E.a(Stream a)
1> at E.GenerateExecutable()
1> at RemObjects.Oxygene.Code.Compiler.Compiler.GenerateExecutable()
1> at RemObjects.Oxygene.Code.Compiler.Compiler.Compile()
1>Done building project “WindowsApplication2.elements” – FAILED.
1>
1>Build FAILED.
========== Build: 0 succeeded or up-to-date, 1 failed, 0 skipped ==========

[mh (marc hoffman)]

@pthompson

Still looks to be a problem, different HRESULT

So that’s with EmbedInteropTypes on, and the two references added by EmbedIneropTyoes off for those?

@pthompson

If I said Embed Interop Types true on the two additional references (office and vbe) then I got this from the build, at which point I stopped digging…

error E0: Internal error: System.NullReferenceException: Object reference not set to an instance of an object.
1> at Mono.Cecil.ParameterDefinition.get_CustomAttributes()
1> at E.a(Object a, Object b, ImmutableArray 1 c, String d) 1> at E.a(Object a, Object b, IGetAttributes c) 1> at E.G.a(IMethodInfo a) 1> at E.f(BaseType a) 1> at E.e(BaseType a) 1> at E.d(BaseType a) 1> at E.G.a(IMethodInfo a) 1> at

That looks like the compiler is still broken, will reopen. Will/does this repro with he testcase you sent, when you add the two references there?

[RemObjectsSoftware (RemObjects)]

bugs://83556 got reopened.