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.