Learn VisualBasic.NET with Me: back on track, ole timeouts

Spending most of the evening thinking about ways to test OLE timeout code (and figuring out how to do it in .NET). The issue is simple: the server app isn’t super-reliable when it handles bad data. So it will probably time out. The goal is to catch this situation, kill the server, record the error, and continue.

References:
How To Handle OLE Automation Server Timeout and Synchronization
App Object for Visual Basic 6.0 Users

OOOH, there’s some really bad news: “OleServerBusyRaiseError: No equivalent. These properties relate to OLE automation, which is not supported by Visual Basic 2005.”

So, I’m kind of screwed here.
This tutorial from SAMS gives some more insight: The Essentials for Using COM in Managed Code
This may also help: Interoperating with COM

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.

Sophomoric summary

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.