Welcome to OStack Knowledge Sharing Community for programmer and developer-Open, Learning and Share
Welcome To Ask or Share your Answers For Others

Categories

0 votes
379 views
in Technique[技术] by (71.8m points)

c# - Exposing Property as Variant in .NET for Interop

I am creating a wrapper class in .NET (VB.NET as it happens but is equally related to C#) that is exposed to COM and one of the properties I am trying to wrap is a Variant. I thought I would just be able to use an Object, but I get an error:

Public Property FieldValue([vFieldID As Object = -1]) As Object cannot be exposed to COM as a property 'Let'. You will not be able to assign non-object values (such as numbers or strings) to this property from Visual Basic 6.0 using a 'Let' statement.*

My property declaration looks like this:

Public Property FieldValue(Optional ByVal vFieldID As Object = -1) As Object
    Get
        Return _objVAccess.FieldValue(vFieldID)
    End Get
    Set(ByVal value As Object)
        _objVAccess.FieldValue = value
    End Set
End Property

My property actually returns a value from the database which can be integer, string, date, etc so it isn't an object in terms of COM. Is there any workaround to this to allow property Let?

See Question&Answers more detail:os

与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
Welcome To Ask or Share your Answers For Others

1 Answer

0 votes
by (71.8m points)

COM Automation supports a default property, the property that has dispid 0. This is used in VB6 code to great effect, generating really compact code. A typical example is:

rs!Customer = "foo"

Which is syntax sugar for:

rs.Fields.Item("Customer").Value = "foo"

Three default properties being used here without being named in the original statement. The Recordset interface has the Fields property as the default property, producing a Fields interface reference. Which has the Item property as the default (indexed) property producing a Field interface reference. Which has the Value property as the default property, producing a variant.

Which is very nice. The price of extreme syntax sugar like this however is tooth decay. There's a syntax ambiguity in a statement like:

Dim obj  
obj = someObject

What is intended here? Do you want to assign the someObject reference to obj? Or do you want to assign the default property of someObject? Very different things, the obj type will be completely different. This was solved in VB6 with the Set keyword. If you want to assign the object reference then you have to write:

Set obj = someObject

And you omit Set or use Let explicitly if you mean to assign the default property value. That's pretty yucky and has bedeviled newbie Visual Basic and VB script programmers for a very long time.

COM Automation implements this by allowing a property to have two setters. Respectively propput and propputref in the IDL where propputref is the one that assigns an object. You can also see this back in the IDispatch definition, the IDispatch::Invoke() method distinguishes between the two with DISPATCH_PROPERTYPUT and DISPATCH_PROPERTYPUTREF.

Zip forward to VB.NET, Microsoft decided that the ambiguity was too painful and eliminated the notion of a default non-indexed property. Which blissfully also retired the Set keyword. This however produces a new problem, there isn't any way anymore to write a [ComVisible] class that can have a property of type Object with a setter that accepts an object reference. The language syntax permits only one setter and the COM interop layer in the CLR is missing the plumbing to synthesize two. Notable is that this is just a warning, you still get the propput setter, you just won't get the propputref setter. Which as far as I can tell is all you want anyway.

Defining the interface either in a VB6 dummy class or by writing the IDL explicitly and compiling it with midl.exe is indeed a way to sail around the warning. As shown by John Rivard in this question.


与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
Welcome to OStack Knowledge Sharing Community for programmer and developer-Open, Learning and Share
Click Here to Ask a Question

...