What you are trying is not valid because the underlying assumption (dynamic
in C# is the same than object
in VB.NET with Option Strict Off
) is not exactly right.
dynamic in C#:
The dynamic type enables the operations in which it occurs to bypass
compile-time type checking. Instead, these operations are resolved at
run time.
For Visual Studio, dynamic
variables can be anything and that's why it will never complain about a given property (or event, like in this case). Your first code is fine because it accepts that _lib
has an event called MessageReceived
(no check is performed).
Option Strict Off in VB.NET:
(when On) Restricts implicit data type conversions to only widening conversions,
disallows late binding, and disallows implicit typing that results in
an Object type.
What means that, with Option Strict Off
, Visual Studio "complains less" in certain situations. To understand the exact implications of the aforementioned not-too-accurate statement, you can either analyse in depth the exact definition of each scenario (e.g., early & late binding) or believe what Visual Studio tells you. Independently upon the option you choose, you will come to the conclusion that, in this specific situation, _lib
has to be casted/converted to the corresponding type (ICapServerLib
) before bringing the event into picture.
Note that .NET 4.0 introduced the System.Dynamic
namespace (at the same time than C# dynamic
). Both VB.NET & C# can deal with the contents of this namespace without any restriction (e.g., https://msdn.microsoft.com/en-us/library/ee461504(v=vs.110).aspx).
I don't have too much experience with the aforementioned namespace and am not sure whether you can perfectly emulate the C# dynamic
behaviour in VB.NET. But I am certain about something: Option Strict Off + Object
is not the same than dynamic
in C#. Also note that the VB.NET WithEvents does not exist in C# and that's why in VB.NET events are treated differently than other properties (unlikely in C#).
NOTE: Hans Passant has written a comment to this question highlighting that late-binding events have never been supported by VB.NET. I am not in a position to (fully) confirm/dismiss such a statement, but will assume that it is right. In that case, the intended direct conversion of the original C# code to VB.NET is not possible.