Hello:

We are now finishing a multi-tier project and have experienced problems in
some of our development machines.

Our project has been divided in three Solutions:

 - 1st: DLL's (Business Façade, Business Logic, Data Access and
SystemFrameworks Layers)

 - 2nd: Remoting Server (almost no code, basically it exposes through
remoting all the classes in the Business Façade of the 1st solution)

 - 3rd: ASP.NET Solution, with all the web forms, that interacts through
the Remoting Server with the Business Façade.

The problem appears with only a few development computers but we need it to
work on them too.

In some cases we have chosen to let certain
"System.Data.OracleClient.OracleException" to propagate throw the Business
Componentes solution to the ASP.NET solution (catching them sometimes but
finally rethrowing them).

While debugging, just before the exception goes out of the scope of the 1st
solution (Business Components), the exception is a real
"System.Data.OracleClient.OracleException", but when we try to catch it in
the general "Application_Error" event of the "global.asax.vb" file in the
ASP.NET application, the exception has ben changed and now it is a
"SerializationException" like this:

System.Runtime.Serialization.SerializationException
Error Message: Member message was not found.

Although I've found a document in the MSDN that shows how to wrap the
exceptions just before having them passed through remoting, just creating a
new exception wrapper inheriting from "ApplicationException" and adding it a
constructor like this:

   // Constructor needed for serialization
   // when exception propagates from a remoting server to the client.
   protected
InvalidDepartmentException(System.Runtime.Serialization.SerializationInfo
info,
       System.Runtime.Serialization.StreamingContext context) {}

...we would like not to have to do it, mainly because now it is working fine
in our Production Environment, and we only have to fix it in some development
machines.

We are still wondering why this is happening.

Meanwhile I'll tell you that our configured channel for remoting
communication is "Http binary", checked in both the remoting server and the
remoting client.

Thank you very much for help in advance.