OOOH, there’s some really bad news: “OleServerBusyRaiseError: No equivalent. These properties relate to OLE automation, which is not supported by Visual Basic 2005.”
Bookmarking progress a few days later
So, I’ve read over the Sams material, and it looks better. It explains that in this .NET system, you can’t do OLE (or ActiveX, or COM) directly. (The relationship between those technologies is reviewed in OLE/ActiveX Scripting Notes.) What .NET does is create assemblies that allow you to interface with a COM instance running outside of .NET’s CLR. (For an explanation of that sentence, see Some COM and .NET Notes.)
Your code runs inside the CLR, and the COM instance runs in the regular Win32 environment. Method calls made onto the interface get translated into method calls on the COM instance. Values returned from the COM instance are translated into .NET values, and returned through the interface. This interface is called an interface assembly, and it’s automatically generated by Visual Studio (or command line tools).
Incidentally, the interface happens down at the COM level, and is called “COM Interop”. So the integration is relatively low-level. OLE and ActiveX features are emulated within .NET, layered on top of the COM interop. The following image, taken from the ESRI doc above, diagrams it:
OLE timeouts are implemented by translating the OLE return values into .NET exceptions. The Sams book has more details. The System.Runtime.InteropServices assembly handles this stuff.
Overall, the setup to use COM objects is extra work, but the code written to handle COM objects is simpler in .NET. Learning about all this is also more work.
What I learned is that .NET really is a “completely new thing” as people were saying (and I was ignoring). It’s practically a new OS for Microsoft, architected, pretty much, the way Java is, except with a lot of hooks back into the Win32 environment.