[Mono-dev] Porting mcs to IKVM.Reflection

[Kornél Pál]

Hi,

Thank you for fixing them.

I've just realized that DefineDynamicAssemblyImpl should not hardcode 
the name "mscorlib" since C# compiler is able to us any name when 
compiling with nostdlib.

Note that a solution would be to modify (and possibliy rename to 
SetMscorlib) LoadMscorlib so that it accepts an Assembly rather than a 
path. It should allow the case when assembliesByName and assemblies only 
contain the specified assembly.

Kornél

Jeroen Frijters wrote:
> Hi Kornél,
> 
> Thanks. Fixed all three issues.
> 
> Regards,
> Jeroen
> 
>> -----Original Message-----
>> From: Kornél Pál [mailto:kornelpal at gmail.com]
>> Sent: Friday, May 07, 2010 6:08 PM
>> To: Jeroen Frijters
>> Cc: mono-devel
>> Subject: Re: Porting mcs to IKVM.Reflection
>>
>> Hi Jeroen,
>>
>> Thank you for the fixes.
>>
>> New problems after the modifications:
>>
>> SetCustomAttribute now fails for example for DllImportAttribute when
>> building mscorlib.dll because ReadFixedArg calls GetEnumUnderlyingType
>> and CheckBaked fails.
>>
>> AssemblyKeyFileAttribute and AssemblyKeyNameAttribute should not be
>> considered pseudo custom attributes because even MS csc.exe emits those
>> attributes and Debug.Assert fails.
>>
>> Also note that according to my tests AssemblyHashAlgorithm.None is
>> changed to AssemblyHashAlgorithm.SHA1 when setting the assembly name
>> because GetName returns AssemblyHashAlgorithm.SHA1 (rather than only
>> when calling Save).
>>
>> Kornél
>>
>> Jeroen Frijters wrote:
>>> Hi Kornél,
>>>
>>> This has now been fixed.
>>>
>>> Thanks,
>>> Jeroen
>>>
>>>> -----Original Message-----
>>>> From: Kornél Pál [mailto:kornelpal at gmail.com]
>>>> Sent: Friday, May 07, 2010 10:33 AM
>>>> To: Jeroen Frijters
>>>> Cc: Marek Safar; mono-devel; Miguel de Icaza
>>>> Subject: Re: Porting mcs to IKVM.Reflection
>>>>
>>>> Hi,
>>>>
>>>> Thank you for applying/enhacing the patches. I'll check it out.
>>>>
>>>> This code will work on both of Mono and MS.NET, but will fail without
>>>> the WriteGenericSignature patch:
>>>>
>>>> AssemblyBuilder ab =
>>>> AppDomain.CurrentDomain.DefineDynamicAssembly(new
>>>> AssemblyName("myassembly"), AssemblyBuilderAccess.Save);
>>>> ModuleBuilder mb = ab.DefineDynamicModule("myassembly",
>>>> "myassembly.dll");
>>>> TypeBuilder tb = mb.DefineType("mytype", TypeAttributes.Public);
>>>> tb.DefineGenericParameters(new string[] { "T", "U" });
>>>> ConstructorBuilder cb =
>>>> tb.DefineDefaultConstructor(MethodAttributes.Public);
>>>> MethodBuilder method = tb.DefineMethod("mymethod",
>>>> MethodAttributes.Static | MethodAttributes.Public, tb,
>>>> Type.EmptyTypes); ILGenerator ig = method.GetILGenerator();
>>>> ig.DeclareLocal(tb); ig.Emit(OpCodes.Newobj, cb);
>>>> ig.Emit(OpCodes.Stloc_0); ig.Emit(OpCodes.Ldloc_0);
>>>> ig.Emit(OpCodes.Ret); tb.CreateType(); ab.Save("myassembly.dll");
>>>>
>>>> Although using a generic type definition directly makes little sense,
>>>> neither makes using tb.MakeGenericType(tb.GetGenericArguments()) much
>>>> more sense, since you still can use the latter in a context that has
>>>> fewer generic arguments.
>>>>
>>>> Kornél
>>>>
>>>> Jeroen Frijters wrote:
>>>>> Hi Kornél,
>>>>>
>>>>> I've fixed most of the things that your patch addressed. I also
>>>> removed support for the TypeForwardedToAttribute and
>>>> DefaultParameterValueAttribute pseudo custom attributes (because I
>>>> realized that supporting them is incompatible with my goal to be a
>>>> drop in replacement for System.Reflection.Emit).
>>>>> One thing I didn't change is WriteGenericSignature, because your
>>>> change didn't make sense to me. It should not be possible that this
>>>> method gets called with a generic type definition.
>>>>> I have not yet added anything additional for version info unmanaged
>>>> resources. I need to do more thinking about this.
>>>>> Regards,
>>>>> Jeroen
>>>>>