[Mono-dev] TypeForwardedFrom
Neale Ferguson
NealeFerguson at verizon.net
Wed Apr 10 23:45:05 UTC 2013
It appears ObjectWriter gets that particular assembly name here:
public int WriteAssembly (BinaryWriter writer, Assembly assembly)
{
return WriteAssemblyName (writer, assembly.FullName);
}
FullName is in Assembly.cs:
public virtual string FullName {
get {
//
// FIXME: This is wrong, but it gets us going
// in the compiler for now
//
return ToString ();
}
}
ToString:
public override string ToString ()
{
// note: ToString work without requiring CodeBase (so no checks are
needed)
if (assemblyName != null)
return assemblyName;
assemblyName = get_fullname ();
return assemblyName;
}
[MethodImplAttribute (MethodImplOptions.InternalCall)]
private extern string get_fullname ();
Where is get_fullname? I can't find it anywhere. In any event just
manipulating the strings isn't good enough, I need the type information to
do the TypeForwardedLookup don't I?
The good news, looking through the serialized object caused me to write a
decoder. It's not complete but it prints some useful stuff:
Element code: 00 (Header)
Element code: 12 (Assembly)
Assembly ID: 2
Assembly Name: Program
Element code: 12 (Assembly)
Assembly ID: 3
Assembly Name: System
Element code: 05 (External Object)
Object ID: 1
Class name:
SerializationPrototype.DataObjectWithObservableCollection
Field count: 3
Field names:
m_stringValue
m_doubleValue
m_collection
Type Tags:
String
Primitive
Generic
Field Specs:
No spec required
(null)
System.Collections.ObjectModel.ObservableCollection`1[[System.String,
mscorlib,
Version=4.0.0.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089]]
[Defined in 3]
External Id: 2
Values:
[4] foo
123
Generic
Element code: 12 (Assembly)
Assembly ID: 6
Assembly Name: WindowsBase
Element code: 05 (External Object)
Object ID: 5
Class name:
System.Collections.ObjectModel.ObservableCollection`1[[System.String,
mscorlib,
Version=4.0.0.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089]]
Field count: 5
Field names:
:
:
<yada yada>
Neale
On 4/9/13 6:11 AM, "Robert Jordan" <robertj at gmx.net> wrote:
> Hi Neale,
>
> It looks like your patch doesn't work correctly, because the
> assembly references are still the same, as if the patch
> didn't have any effect.
>
> Assembly references start with "ff" in your dump ("ff" is
> decimal 12). See:
>
> https://github.com/mono/mono/blob/master/mcs/class/corlib/System.Runtime.Seria
> lization.Formatters.Binary/binary_serialization_format.htm
>
>
> | ID (LE) | String length | String (assembly name)
> --------------------------------------------------------------
> Mono: 12 | 3 0 0 0 | 6 | System
> Windows: 12 | 3 0 0 0 | 78 | WindowsBase, Version=...
>
>
> I had a look at Mono's
>
> System.Runtime.Serialization.Formatters.Binary/ObjectWriter.cs
>
> and it seems that the necessary patch isn't quite a smooth sailing.
> The code is dealing with Assembly objects which we don't have
> if TypeForwardedFrom is in effect. The code must be somehow
> changed to deal with plain assembly names (strings).
>
> I'd rename ObjectWriter.WriteAssembly to ObjectWriter.WriteTypeAssembly
> and pass it a Type in place of the type's Assembly object.
>
> Whatever you do, don't forget that there is another
> fast serializer implemented in CodeGenerator.cs which must be
> kept in sync with ObjectWriter.cs
>
> Robert
>
>
> On 09.04.2013 00:18, Neale Ferguson wrote:
>> Hi,
>> I've taken your code as a base for creating a test fix. It works nicely but
>> .NET appears to be doing something a little strange (in my eyes, not theirs
>> of course). A program (such as shown in bugzilla 11294) when run creates a
>> serialized object but the header contents are different:
>>
>> Mono -
>>
>> 0000000 nul soh nul nul nul del del del del soh nul nul nul nul nul nul
>> 0000020 nul ff stx nul nul nul bel P r o g r a m ff etx
>> 0000040 nul nul nul ack S y s t e m enq soh nul nul nul 9 <==
>> 0000060 S e r i a l i z a t i o n P r o
>> 0000100 t o t y p e . D a t a O b j e c
>> 0000120 t W i t h O b s e r v a b l e C
>> 0000140 o l l e c t i o n etx nul nul nul cr m _
>> 0000160 s t r i n g V a l u e cr m _ d o
>> 0000200 u b l e V a l u e ff m _ c o l l
>> 0000220 e c t i o n soh nul eot ack dc3 soh S y s t
>> 0000240 e m . C o l l e c t i o n s . O
>> 0000260 b j e c t M o d e l . O b s e r
>> 0000300 v a b l e C o l l e c t i o n
>>
>> Windows -
>>
>> 0000000 nul soh nul nul nul FF FF FF FF soh nul nul nul nul nul nul
>> 0000020 nul ff stx nul nul nul > P r o g r a m , sp
>> 0000040 V e r s i o n = 0 . 0 . 0 . 0 ,
>> 0000060 sp C u l t u r e = n e u t r a l
>> 0000100 , sp P u b l i c K e y T o k e n
>> 0000120 = n u l l ff etx nul nul nul N W i n d o <==
>> 0000140 w s B a s e , sp V e r s i o n =
>> 0000160 3 . 0 . 0 . 0 , sp C u l t u r e
>> 0000200 = N e u t r a l , sp P u b l i c
>> 0000220 K e y T o k e n = 3 1 b f 3 8 5
>> 0000240 6 a d 3 6 4 e 3 5 enq soh nul nul nul 9 S
>> 0000260 e r i a l i z a t i o n P r o t
>> 0000300 o t y p e . D a t a O b j e c t
>> 0000320 W i t h O b s e r v a b l e C o
>> 0000340 l l e c t i o n
>>
>> Note, that Mono associates System with Program, but .NET associates it with
>> WindowsBase. I'm not sure why it does this.
>>
>> On 4/5/13 10:14 AM, "Robert Jordan" <robertj at gmx.net> wrote:
>>
>>> You don't need to know how mcs operates. The TypeForwardedFrom
>>> information can be obtained via reflection:
>>
>>
>> _______________________________________________
>> Mono-devel-list mailing list
>> Mono-devel-list at lists.ximian.com
>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>
>
More information about the Mono-devel-list
mailing list