I have a very strange error; an ASP page invokes a method through .NET
remoting which returns an exception as an output parameter.
Unfortunately, no matter what exception the method returns, it appears
as a different one ("Cannot find the assembly") to the ASP page.

To clarify, I have an interface class called called IGetBoardInfo,
which provides the interface for one method.

I have a Windows service that exposes (through remoting) a class called
GetBoardInfo, which implements the interface.  It uses a class library
called SubComponent, which can throw custom exceptions.

Finally, an ASP webpage instantiates the GetBoardInfo class and calls
its method.  When it does, the GetBoardInfo class calls SubComponent,
which throws a SubComponentException, which is returned via output
parameter back to the ASP page.  The problem is, which the ASP page
tries to display the exception's message, this is the exception that
appears:

"Cannot find the assembly 'SubComponent', Version=1.0.1.2,
Culture=neutral, PublicKeyToken=null."

This is not the exception that was actually thrown.  How is the real
exception getting obscured, and this other exception being shown
instead?



Here is some much-simplified code that illustrates what I'm talking
about:

The interface class is specified like this:

namespace TE.Service.IGetBoardInfo
{
    [Serializable()]
    public struct BoardInfo
    {
        public long m_ID;
        public long m_siteNumber;
    }

    public interface IBoardInfo
    {
        BoardInfo[] GetBoardInfo(out Exception o_exception);
    }
}

The service itself is called GetBoardInfoSvc, and uses a C# class
library called SubComponent.

public class BoardInfoRpcServer : MarshalByRefObject, IBoardInfo
{
    public BoardInfo[] GetBoardInfo(out Exception o_exception)
    {
        o_exception = null;
        BoardInfo[] info = null;
        try
        {
            // this line throws a SubComponentException
            info = SubComponentNamespace.SubComponent.GetBoards();
        }
        catch(Exception e)
        {
            o_exception = e;
            info = null;
        }

        return info;
    }
}


The webpage has code that looks like this:

Private Sub Page_Load(ByVal sender As System.Object, ByVal e As
ystem.EventArgs) Handles MyBase.Load
    Dim url as String = "tcp://myComputerName:555/GetBoardInfo.rpc"
    Dim obj As IBoardInfo = Activator.GetObject(GetType(IBoardInfo), url)
    Dim exBoardInfo As Exception

    Dim strBoards() As BoardInfo = obj.GetBoardInfo(exBoardInfo)

    ' At this point, exBoardInfo is "Cannot find the assembly
'SubComponent'",
    ' which is not the exception that was originally thrown.
End Sub

Hi!

Why did you choose to use an output parameter to notify the caller about
exceptions? When you throw an exception within the server method, it will
get automaticly serialized to the client. The remoting infrastructure then
throws the exception on the caller side. There is no need for an output
parmeter. An output parmeter can be ignored, a thrown exception not.

But this will not solve your problem. I think that the problem is the
Exception call itself. The instance of the exception call is not special in
case of remoting. What I want to say is that

1. the Exception instance has to be seralized to the client (Serializable
Attribute, ISerializable)
2. the Assembly where the Exception is declared has to be available on the
client side

It seems that the client is not able to find the Assembly where the
exception class is definied. This is the reason for the

exception. The "Cannot find the assembly" Exception is thrown on the client,
it cannot be that your o_exception (in C# hungarian notation is very
uncommon) contains it.



OK?
br GP

dves***@gmail.com wrote:
Show quoteHide quoteRun FUSLOGVW.exe from the .Net SDK.  This gives additional details about
what is going on in the assembly loader.

dves***@gmail.com wrote:

Examine the Stack Trace of the Exception and find out where the
TypeLoadException is happening.

It is likely that the ASP application is unable to load the Assembly
that defines the Custom Exception class that you are initially throwing.

Whenever you throw a Custom exception then any application wishing to
process that Exception /must/ be able to load its definition, to find
out what it can do with the object.
If the "client" application is unable to load this defining Assembly,
this is the error you get.

HTH,
    Phill  W.

Application changes propagating through the system
Wait for all ThreadPool workers to complete
Exe + dll system.management.dll
Advertising On msnews; Legal or Illegal?!?
TreeView