After further reading, it turns out Rick did address the dynamic COMReturnError() issue directly.

It shows us the error that occurs in .NET but unfortunately no further error information in Visual FoxPro. Rats... Unfortunately this is one of the downsides of the new dynamic functionality – when an error occurs in the COM object we just get a generic error returned.
If you want to find out what REALLY happened you have to resort to Reflection to get more information unfortunately. The ComHelper class includes CallMethod() that does just that.

I actually attended this session at SW Fox, but I didn't realize how much good additional info was in the white paper. I'm going to study it thoroughly. Thanks again!

>It looks like Rick checks the return value of the COM object method, then throws an exception if there is a problem (code below). Not exactly what I'm looking for, but probably a best practice anyway. Thanks.
>

>// create a FoxPro business object 
>dynamic entry = fox.ComHelper.CreateObject("blog_entry");
>
>// Call Load() method on FoxPro business object 
>if (!entry.Load(id)) 
>     throw new ApplicationException("Invalid Id passed.");
>

>
>>Have you looked at http://www.west-wind.com/presentations/AspNetFoxProRevisited.pdf?
>>
>>
>>>I've been struggling with this one all day. There are two parts. First, as you may be aware, C# added a dynamic type recently that makes it easier to work with COM objects. Instead of adding the COM object as a reference to the .NET project and creating a Runtime Callable Wrapper (RCW), you can simply instantiate it like so:
>>>

>>>dynamic FoxObject = Activator.CreateInstance(Type.GetTypeFromProgID("MyFoxPro.COMObject"));
>>>

>>>This works great, except when it comes to errors that occur inside the FoxPro object. COMReturnError() (or no error handler at all) doesn't return the specified info, but rather generates the following error in .NET:
>>>
>>>System.NullReferenceException: Object reference not set to an instance of an object.
>>>
>>>Maybe there is some way to tell .NET: "Hey! This dynamic object is in fact a COM object and you need to look at the COM exception info when an error occurs"? That's part one and maybe the answer will help, but actually, the way I call into COM objects I usually get a "Feature not available" error when I try to use COMReturnError() anyway. So that leads to part two...
>>>
>>>As an alternative to COMReturnError(), I tried creating my own callback object and have .NET trigger the exception. Here's the callback class code:
>>>

>>>    [ComVisible(true)]
>>>    public class DotNetCallback
>>>    {
>>>
>>>        // COMReturnError() doesn't work the way we are handling method calls, so use callback instead
>>>        public void ThrowException(string ExceptionText)
>>>        {
>>>            throw new Exception(ExceptionText);
>>>        }
>>>    }
>>>

>>>I pass the callback object to FoxPro, then call the ThrowException() method from FoxPro, rather than COMReturnError(). The problem is that the exception comes back to FoxPro rather than interrupting the currently running ASP.NET MVC request. That's probably exactly what it should do, but then besides an Exception, how else can I interrupt running code in ASP.NET and report the error? Would a redirect do the trick, or will the remaining code in the interrupted method finish running?
>>>
>>>Hope this makes sense. Thanks.