|
Bugzilla – Full Text Bug Listing |
| Summary: | Can not pass CallContext slot via HTTPChannel + SoapFormatterSink | ||
|---|---|---|---|
| Product: | [Mono] Mono: Runtime | Reporter: | Michail Ushakov <migelU> |
| Component: | remoting | Assignee: | Lluis Sanchez <lluis> |
| Status: | RESOLVED DUPLICATE | QA Contact: | Mono Bugs <mono-bugs> |
| Severity: | Major | ||
| Priority: | P5 - None | CC: | gert.driesen, robertj |
| Version: | SVN | ||
| Target Milestone: | --- | ||
| Hardware: | i686 | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
| Found By: | DeveloperNet | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: | Call context data pass through SoapFormatter | ||
What version of Mono are you using? It works fine for me (on Windows XP) using SVN head. Gert, did you also test the interoperability? Yes, I did: * Mono 1.0 client <-> .NET 1.1 server * .NET 1.1 client <-> Mono 1.0 server (always using Mono on Windows though) We use Mono 1.9.1 (RTM and SVN head also) Did you run my test project under MS.NET 2.0 and Mono 1.9.1 ? We use MS.NET 2.0 and Mono 1.9.1 Michail, I also tried the following without any problem: * Mono 2.0 client <-> .NET 2.0 server * .NET 2.0 client <-> Mono 2.0 server Can you try using SVN HEAD, or Mono 2.0 p1? Mono 2.0 beta 2
Mono JIT compiler version 2.0 (tarball)
Copyright (C) 2002-2008 Novell, Inc and Contributors. www.mono-project.com
TLS: normal
GC: Included Boehm (with typed GC)
SIGSEGV: normal
Notification: Thread + polling
Architecture: x86
Disabled: none
all works fine
For the records: this was fixed post 1-9 in r95498. It's still open, but it has a patch: bug #422491. *** This bug has been marked as a duplicate of bug 422491 *** |
Created attachment 225395 [details] Call context data pass through SoapFormatter Hello We use CallContext depended data In our remoting scenario. This data contains reference to the MBR object. But runing our project under MONO runtime leads to exception: System.Runtime.Serialization.SerializationException: The object with ID 4 could not be resolved at System.Runtime.Serialization.ObjectManager.DoFixups () [0x00000] at System.Runtime.Serialization.Formatters.Soap.SoapReader.get_TopObject () [0 x00000] at System.Runtime.Serialization.Formatters.Soap.SoapReader.Deserialize (System .IO.Stream inStream, ISoapMessage soapMessage) [0x00000] at System.Runtime.Serialization.Formatters.Soap.SoapFormatter.Deserialize (Sys tem.IO.Stream serializationStream, System.Runtime.Remoting.Messaging.HeaderHandl er handler) [0x00000] at System.Runtime.Serialization.Formatters.Soap.SoapFormatter.Deserialize (Sys tem.IO.Stream serializationStream) [0x00000] at System.Runtime.Remoting.Channels.SoapClientFormatterSink.DeserializeMessage (System.IO.Stream responseStream, ITransportHeaders responseHeaders, IMethodCal lMessage mcm, System.Runtime.Remoting.Channels.SoapMessageFormatter soapMsgForma tter) [0x00000] at System.Runtime.Remoting.Channels.SoapClientFormatterSink.SyncProcessMessage (IMessage msg) [0x00000] at System.Runtime.Remoting.Proxies.RemotingProxy.Invoke (IMessage request) [0x 00000] at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke (System.Runtime.Rem oting.Proxies.RealProxy rp, IMessage msg, System.Exception& exc, System.Object[] & out_args) [0x00000] MSVC 2005 solution for bug reproducing in attachment