Call a method in a different AppDomain. Return this value type from the
method.
.class private sequential ansi serializable sealed beforefieldinit a
extends [mscorlib]System.ValueType
{
.field assembly class [mscorlib]System.Reflection.AssemblyName a
.field assembly string a
.method assembly hidebysig specialname rtspecialname
instance void .ctor(class
[mscorlib]System.Reflection.AssemblyName name,
string location) cil managed
{
// Code size 15 (0xf)
.maxstack 2
IL_0000: ldarg.0
IL_0001: ldarg.1
IL_0002: stfld class [mscorlib]System.Reflection.AssemblyName
a::a
IL_0007: ldarg.0
IL_0008: ldarg.2
IL_0009: stfld string a::a
IL_000e: ret
} // end of method a::.ctor
} // end of class a
This code actually exists as part of my obfuscator, Demeanor. So I ran
into the bug while debugging Demeanor. Basically, (I think based on some
conversations plus experimentation) that the serialization code persists
the two fields called 'a' successfully. But the deserialization code
gets one of the two saved values, finds an 'a' field and attempts to set
it. However as it's not looking for a 'a' field of a particular type, it
may set the right one or it may try and set the wrong one. Even if it
works for setting the first 'a', it'll get the first one again while
trying to set the second field's value. It then has a type mismatch
problem.
Unhandled Exception: System.ArgumentException: Object type cannot be
converted to target type.
Server stack trace:
at System.Reflection.RuntimeFieldInfo.InternalSetValue(Object obj,
Object val, BindingFlags invokeAttr, Binder binder, CultureInfo culture,
Boolean requiresAccessCheck, Boolean isBinderDefault)
at
System.Runtime.Serialization.FormatterServices.SerializationSetValue(Mem
berInfo fi, Object target, Object value)
at
System.Runtime.Serialization.FormatterServices.PopulateObjectMembers(Obj
ect obj, MemberInfo[] members, Object[] data)
at
System.Runtime.Serialization.Formatters.Binary.ReadObjectInfo.PopulateOb
jectMembers(Object obj, Object[] memberData)
at
System.Runtime.Serialization.Formatters.Binary.ObjectReader.ParseObjectE
nd(ParseRecord pr)
at
System.Runtime.Serialization.Formatters.Binary.ObjectReader.Parse(ParseR
ecord pr)
at
System.Runtime.Serialization.Formatters.Binary.__BinaryParser.Run()
at
System.Runtime.Serialization.Formatters.Binary.ObjectReader.Deserialize(
HeaderHandler handler, __BinaryParser serParser, Boolean fCheck,
IMethodCallMessage methodCallMessage)
at
System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deseriali
ze(Stream serializationStream, HeaderHandler handler, Boolean fCheck,
IMethodCallMessage methodCallMessage)
at
System.Runtime.Remoting.Channels.CrossAppDomainSerializer.DeserializeObj
ect(MemoryStream stm)
at
System.Runtime.Remoting.Channels.CrossAppDomainSerializer.DeserializeMes
sageParts(MemoryStream stm)
at
System.Runtime.Remoting.Messaging.SmuggledMethodReturnMessage.FixupForNe
wAppDomain()
at
System.Runtime.Remoting.Channels.CrossAppDomainSink.SyncProcessMessage(I
Message reqMsg)
Exception rethrown at [0]:
at
System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessagere
qMsg, IMessage retMsg)
at
System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData&msgD
ata, Int32 type)
at b.a(String a)
at l.a(Boolean a, b b, String c, String d)
at l.a(Boolean a, Boolean b)
at c.a(String[] a)
-- Brent Rector, .NET Wise Owl
Demeanor for .NET - an obfuscation utility
http://www.wiseowl.com/Products/Products.aspx
-----Original Message-----
From: Ted Neward [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, May 15, 2002 4:18 PM
To: [EMAIL PROTECTED]
Subject: Re: [DOTNET] Obscure .NET Deserialization bug
How on earth did you find this? I'd love to see the test case.
Ted Neward
{.NET || Java} Course Author & Instructor, DevelopMentor
(http://www.develop.com)
http://www.javageeks.com/tneward http://www.clrgeeks.com/tneward
----- Original Message -----
From: "Brent E. Rector" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, May 15, 2002 1:29 PM
Subject: [DOTNET] Obscure .NET Deserialization bug
> I doubt anyone else will run into this bug however I'm posting it for
> the archives.
>
> The CLR determines uniqueness of a member of a class using the
> name/signature tuple. That is, the CLR is perfectly happy encountering
> an 'int a' and a 'double a' in the same scope. Unfortunately, I found
> out last night, the deserialization part of remoting isn't. It relies
> on uniqueness of names only. This is a known bug and will be fixed in
> some future version.
>
> -- Brent Rector, .NET Wise Owl
> Demeanor for .NET - an obfuscation utility
> http://www.wiseowl.com/Products/Products.aspx
>
> You can read messages from the DOTNET archive, unsubscribe from
> DOTNET, or subscribe to other DevelopMentor lists at
> http://discuss.develop.com.
>
You can read messages from the DOTNET archive, unsubscribe from DOTNET,
or subscribe to other DevelopMentor lists at http://discuss.develop.com.
You can read messages from the DOTNET archive, unsubscribe from DOTNET, or
subscribe to other DevelopMentor lists at http://discuss.develop.com.
