This project has moved and is read-only. For the latest updates, please go here.

xxx is not a member of 'LateBindingApi.Core.COMObject'

Apr 10, 2012 at 6:43 PM


I'm using NetOffice with ExcelDna and VB.Net to convert a VBA addin to VB.Net
One common problem is the error message above.

 I have to rewrite chained properties like this:



as separate calls using a variant Object type.

 Is  there an easier way than all this rewrite? There are hundreds of them.




Apr 10, 2012 at 7:22 PM

Hey Patrick,

thats what i'm walking in our e-mail discussion.
the current NetOffice release converts unkown COM Proxies to the type COMObject.
this is a good way for the typesafe design but not easy to handle for VB/VBA developers.
govert shows me this problem as first. what you can do at the moment is: store the property in a local variable as Object
and use Visual Basic latebinding now. i do the change to Object for anyoynm proxies as fast as possible. a new release is planned for the next weekend.


Apr 11, 2012 at 9:54 AM

Thanks, Sebastian,
It's great if you can change things at your end to avoid a lot of workarounds in the code.
I'd like to avoid late binding because it loses intellisense and pushes errors to runtime, but for generic objects like .Sheets(n) and .Parent it's unavoidable.

I have other questions, probably basic, but I imagine that if I post them here at the discussion it may help others find the answers through google.


Apr 11, 2012 at 10:04 AM

avoid latebinding is not impossible but you need some casts at runtime. (more code)
its okay for the simples things to use latebinding in VB i find.


Apr 11, 2012 at 10:16 AM

"you need some casts at runtime"

Yes, I discovered the use of eg

dim cdp as NetOffice.OfficeApi.documentproperties

cdp = CType( wb.CustomDocumentProperties, Netoffice.Officeapi.documentproperties)

I'll post separate questions if that's OK to keep threads together.