Actually, we do support it. try setting the option on the reference in the project and see f that does the trick?
bugs://83539 got closed with status nochangereq.
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=188.8.131.52, 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 ?
I’m confused between:
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)|
|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?
Thanks, logged as bugs://83556
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=184.108.40.206, Culture=neutral, PublicKeyToken=71e9bce111e9429c)
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
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.
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).
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 ?
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 ?
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
bugs://83556 got closed with status fixed.
But only when EmbedInteropTypes is on? Why didn’t these error show with it off?
Because when embedding I copy the types over. Part of this is copying the signatures over.
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.
Thanks Marc. I’ll try and take a look later this afternoon, but may be tomorrow…
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, 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 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.
========== Build: 0 succeeded or up-to-date, 1 failed, 0 skipped ==========
So that’s with EmbedInteropTypes on, and the two references added by EmbedIneropTyoes off for those?
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?
bugs://83556 got reopened.