[Mono-dev] Porting mcs to IKVM.Reflection

[Kornél Pál]

Hi,

If I look at it form an API design point of view netiher LoadMscorlib 
nor SetMscorlib are good.

LoadMscorlib was designed to meet your very specific needs of being able 
to load mscorlib.dll from a specified file.

SetMscorlib would remove the restriction of loading from the file and 
also would be future proof in the sense that it will continue to be 
compatible with new assembly loading/creating methods and new overloads 
of existing methods without any modification required.

As I see the only was mscorlib.dll could be compiled is that you don't 
load another mscorlib.dll in DefineDynamicAssembly or in AssemblyBuilder 
constructor. This would be the defined behavior. Right not I cannot 
think of any possible requirement for loading mscorlib.dll during 
DefineDynamicAssembly. Since mscorlib.dll is a corner case if you will 
have to load mscolib.dll anyway intorducing another solution would only 
break a marginal set of all the use cases (mainly mcs when building 
mscorlib.dll) so such a breaking change would be acceptable. And I think 
that if such a requirement would be introduced that would be a breaking 
change in MS.NET as well.

As a conclusion I think that there are only two properly designed solutions:
1. Remove LoadMscorlib, make HasMscorlib internal, and rely on 
AssemblyResolve event handler.
2. Remove LoadMscorlib, remove HasMscorlib, and add two new methods: 
__AddAssembly(string refname, Assembly asm)
__TryGetAssembly(string refname, out Assembly asm)

The first solution is very straightforward, and I've attached a patch 
for the second one (it's very straightforwad as well but was easier to 
express myself by using a patch).

I consider the second one to be a more proper solution because compiler 
writers usually prefer to load a set of assemblier themselves rather 
than rely on automatic assembly resolution. Since Universe design in 
based on mapping System.Types to IKVM.Reflection.Types, compiler writers 
might actually use typeof for other assemblies (not just mscorlib.dll) 
and they might want those assembiles to be resolved to their preferred 
assembly. An example for such a behavior is a VB.NET compiler that has 
its own Microsoft.VisualBasic.dll runtime library treated very similar 
to how mscorlib.dll is treated by a C# compiler. VB runtime is written 
in VB and a /novbruntimeref option is required to build the runtime.

Regards,
Kornél

Jeroen Frijters wrote:
>> Please see the attached patch.
>>
>> I belive that this is actually an easier and cleaner solution than the
>> current one.
> 
> I disagree. You have to look at it from an API development point of view. This creates a huge window for undefined behavior and dependencies on implementation specifics, between calling DefineDynamicAssembly and SetMscorlib. It also makes it impossible for DefineDynamicAssembly (or the AssemblyBuilder constructor) to do anything that requires mscorlib (and who knows, maybe some future change to reflection will require this).
> 
> Regards,
> Jeroen
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: asm_diff.txt
Url: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20100509/55d50fce/attachment-0001.txt