Hi,
I'm trying to keep differences minimal, and I have no intention to
drop System.Reflection support:
#if IKVM_REF_EMIT
using IKVM.Reflection;
using IKVM.Reflection.Emit;
using Type = IKVM.Reflection.Type;
#else
using System.Reflection;
using System.Reflection.Emit;
#endif
I'd prefer
Hello Kornél,
Thanks for the proof of concept of using System.Reflection.Emit with
latest gmcs. I'll look into this more deeply when I iron out all
regressions caused by the big change.
It would be interesting to get some numbers out, I don't believe there
should be much difference between
Hi Kornél
Can you please tell when are MakeExpression methods used and whether
are they required for code generation by mcs? The problem is that SLE
MakeExpression methods require System.Reflection types. I was unable
to find out when are MakeExpression methods used so I cannot come up
I'm just trying to implement /nostdlib:
http://msdn.microsoft.com/en-us/library/fa13yay7.aspx
And I belive that having API for setting assembly aliases would be a
good solution.
Of course LoadMscorlib is not a bug, it's just redundant. The current
AssemblyResolve is able to do that just fine.
Hi Kornél,
I'm just trying to implement /nostdlib:
http://msdn.microsoft.com/en-us/library/fa13yay7.aspx
And I belive that having API for setting assembly aliases would be a
good solution.
I think I understand better where you're coming from now. I did some more work
on it in the mean
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
LoadMscorlib was designed to meet your very specific needs of being able
to load mscorlib.dll from a specified file.
Any API designed without a very specific use case is doomed, so I consider this
a feature not a bug.
I don't understand what problem you are trying to solve, so maybe we should
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
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.
The hardcoded name bother me too, but then I couldn't think of any realistic
scenario where you'd build an mscorlib with a different
Hi,
There simply is no special case for building mscorlib.dll.
There is a /nostdlib option however that enables features required for
building mscorlib.dll.
I would recommend SetMscorlib over LoadMscorlib because that would not
restrict how you can create or load mscorlib.dll.
Kornél
Jeroen
I would recommend SetMscorlib over LoadMscorlib because that would not
restrict how you can create or load mscorlib.dll.
That feels like painting yourself into a corner to me. Using SetMscorlib would
require modifying DefineDynamicAssembly in a way that would make it hard to
remain compatible
Please see the attached patch.
I belive that this is actually an easier and cleaner solution than the
current one.
You can use Load, LoadFile, DefineDynamicAssembly, etc. to load
mscorlib.dll.
Kornél
Jeroen Frijters write:
I would recommend SetMscorlib over LoadMscorlib because that
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,
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
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),
This code will work on both of Mono and MS.NET, but will fail without
the WriteGenericSignature patch:
[...]
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
Hi Kornél,
This has now been fixed.
Thanks,
Jeroen
-Original Message-
From: Kornél Pál [mailto:kornel...@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
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
Hi Kornél,
Thanks. Fixed all three issues.
Regards,
Jeroen
-Original Message-
From: Kornél Pál [mailto:kornel...@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.
Hi,
Can you please tell when are MakeExpression methods used and whether are
they required for code generation by mcs? The problem is that SLE
MakeExpression methods require System.Reflection types. I was unable to
find out when are MakeExpression methods used so I cannot come up with a
Hi Marek,
Thank you for your reply.
I'm trying to keep differences minimal, and I have no intention to drop
System.Reflection support:
#if IKVM_REF_EMIT
using IKVM.Reflection;
using IKVM.Reflection.Emit;
using Type = IKVM.Reflection.Type;
#else
using System.Reflection;
using
My understanding is that basically we only have two compilers:
- static: mcs.exe, gmcs.exe, smcs.exe, dmcs.exe (for each profile)
- dynamic: Mono.CSharp.dll, that is used by Microsoft.CSharp.dll and
csharp.exe
As I see (based on your explanation) only the dynamic (as in the
Kornél Pál wrote:
mcs creates an assembly, then creates types, and only after that is
processing the custom attributes. This is how attributes and even
assembly name (not the name part) can change after definition. Although
there are some other self referencing cases, this order of
Hi,
I'm still in the stage of getting the things work, so I haven't really
care about performance yet, but I'll give you some numbers once I
consider the patch complete.
Also note that IKVM.Reflection support is implemented using conditional
compilation directives, so adding support for
Hi,
Jeroen Frijters wrote:
Kornél Pál wrote:
mcs creates an assembly, then creates types, and only after that is
processing the custom attributes. This is how attributes and even
assembly name (not the name part) can change after definition. Although
there are some other self referencing
Hi,
Thanks for the IKVM.Reflection patches. I have a few questions about some of
the changes.
- Why are the various _SetAttributes methods and the
AssemblyBuilder.__SetName() methods necessary?
- Do you really need blob encoded pseudo custom attributes in the version info?
I intentionally
Hi,
mcs creates an assembly, then creates types, and only after that is
processing the custom attributes. This is how attributes and even
assembly name (not the name part) can change after definition. Although
there are some other self referencing cases, this order of
creation/definition is
27 matches
Mail list logo
