dotnet remoting:
Hi,

I've encountered a problem with a cross-firewall Remoting application which
uses a BinaryFormatter. The application was built with Framework 1.1 and
works fine when accessed from 1.1 applications, but throws the following
exception when accessed from a framework 2.0 application:

Error Source :mscorlib

Error Stack Trace :
Server stack trace:
at System.Runtime.Remoting.Channels.Tcp.TcpReadingStream.Flush()
at System.Security.Cryptography.CryptoStream.FlushFinalBlock()
at System.Security.Cryptography.CryptoStream.Dispose(Boolean disposing)
at System.IO.Stream.Close()
at
System.Runtime.Remoting.Channels.BinaryClientFormatterSink.SyncProcessMessage(IMessage msg)

Exception rethrown at [0]:
at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage
reqMsg, IMessage retMsg)
at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData&
msgData, Int32 type)
at DMZSender.DMZSenderLib.GetDataView(String SQL, String tableName,
String[] aliasArgs)
at COL.Security.SecurityManager.GetDataView(String sql, String tableName,
String[] aliasArgs)
at TestTiming.WebForm1.Page_Load(Object sender, EventArgs e)

Error TargetSite :Void
HandleReturnMessage(System.Runtime.Remoting.Messaging.IMessage,
System.Runtime.Remoting.Messaging.


Any suggestions are appreciated.

I have the exact same problem. Have you had any luck in solving the issue?
---

[quoted text, click to view]

Unfortunately, I never solved the problem, even with extensive
assistance from Microsoft. The problem occurs inside of an
EncryptionSink DLL which we had copied from the Ingo Rammer Advanced
..Net Remoting book (as have many others).

What seems to happen is that the calling application invokes the
remoting stack as a 2.0 application, but the reply comes back as a 1.1
application. The calling application appears to load the 2.0 version
of System.Runtime.Remoting.Channels.Tcp, but the reply seems to invoke
the 1.1 version when it tries to decrypt the response. The 2.0 version
of the TcpReadingStream object no longer provides a Flush method, but
the 1.1 version did. So I get the "Method not found" exception.

While working on this problem I found out that Microsoft has provided
native support for encryption if you use 2.0 Remoting, so I'm just
going to sidestep the whole problem and do that. It allows me to get
rid of the EncryptionSink.

Of course this last approach creates a new problem which is that you
need to be able to authenticate the user who originates the remoting
request, which is not possible from the DMZ, if you want to use
encryption. Oh well ...