.Net Remoting serialization issue

Question

I've an issue with the .Net Remoting:

We have two application, a client and a server. The client can connect to the server and retrieve a configuration through .Net Remoting.

We have a setup which allows to deploy our software to the client. This setup obfuscate all our code, but we have an exclusion list (through namespace and DLL) which is excluding all class that are used to transfer data.

It appeared recently that since several months, we have a class in the configuration which is serialized, which is wrong. We saw that because we can't connect anymore from a debug client to a release(setup) server.

The issue is now: how can we find this class.

The exception is the following:

System.Runtime.Serialization.SerializationException occurred
  HResult=-2146233076
  Message=Cannot get the member '<.ctor>b__5'.
  Source=mscorlib
  StackTrace:
    Server stack trace: 
       at System.Reflection.MemberInfoSerializationHolder.GetRealObject(StreamingContext context)
       at System.Runtime.Serialization.ObjectManager.ResolveObjectReference(ObjectHolder holder)
       at System.Runtime.Serialization.ObjectManager.DoFixups()

We tried to see with the deobfuscator what member it is but it seems that the exception isn't complete enough.

We have a lot of class, heritage, ... and we currently can't find which class is obfuscated but should not.

Since it's a binary serialization, we cannot see easily what is transfered between client and server.

What would be the better way(modifying the less the current code) to find which is the obfuscated class?

EDIT In addition of the dburner answer, I would like to say that I've removed my delegate and used direct method. Like this, this name is fixed and should not change depending of the compilation.

`b__5` appears to be an auto generated class. The C# compiler generates nested types(with `_` in the name) to resolve the captured variables problem. See this article http://blogs.msdn.com/b/matt/archive/2008/03/01/understanding-variable-capturing-in-c.aspx . I think there may be some other cases where the compiler will generate nested types. — dburner, Apr 08 '14 at 11:11
That seems very plausible to me, I currently put a two method with `[OnDeserializing()]` and `[OnDeserialized()]` attributes, and I arrived in a class which has a Func as private field. What namespace would have this class? — J4N, Apr 08 '14 at 11:20
And in fact, why do you think that the client cannot deserialize this class? — J4N, Apr 08 '14 at 11:41
I didn't said that. I was only making an observation. But searching a bit I found out that serializing delegates is a tricky process because delegates are pointers to a location in memory witch can change can vary. — dburner, Apr 08 '14 at 14:37
Remoting is a legacy technology that is retained for backward compatibility with existing applications and is not recommended for new development. Distributed applications should now be developed using WCF or ASP.NET Web API. See the note at the top of http://msdn.microsoft.com/en-us/library/vstudio/xws7132e.aspx for proof. — John Saunders, Apr 08 '14 at 15:27
I'm not sure to understand how your comment help. We have to maintain an application. I know very well WCF and I would love to use it, but it's not in my hand and not my question. — J4N, Apr 08 '14 at 15:41
My comment was intended to ensure that you (and future readers) were aware that Remoting is now a legacy technology. You'd be surprised how many developers may find an old article on the Internet and think that Remoting is a current technology. — John Saunders, Apr 08 '14 at 15:49

score 2 · Accepted Answer · edited May 23 '17 at 10:30

2

Take a look at this question Could we save delegates in a file (C#)

Delegates can be serialized and deserialized in the same application if you are lucky because they are pointers to function and a function can have diferent memory locations.

Because you are trying to deserialize your class in another application you are getting weird errors.

edited May 23 '17 at 10:30

Community

1
1

answered Apr 08 '14 at 15:19

dburner

1,007
7
22

1

Yeah, I'm coming at the same results, since it's at the compilation time that VS studio decide which name a delegate will receive, we are not sure that between two compilation we will get the same result. In my case it's the same class but once compiled from a build machine, and the other time on my local workstation – J4N Apr 08 '14 at 15:44

.Net Remoting serialization issue

1 Answers1