Generally it's safe to assume that whatever Rick is doing is a best practice. My admiration of him knows no bounds. And he shares his knowledge freely.

>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.