[Mono-dev] Porting mcs to IKVM.Reflection
kornelpal at gmail.com
Sun May 9 06:36:01 EDT 2010
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.
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).
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
More information about the Mono-devel-list