<Chuckle>
Heh, heh... it seems like people on this list have real jobs keeping them
busy. Glad to see I'm not the only one who has to trade fun work for a
paycheck.
</Chuckle>
<Disclaimer>
Keep in mind this is the first time I look at any metadata code, so take
whatever I say below with a good intake of salt.
</Disclaimer>
I can reproduce the behavior you are talking about and yes, csc.exe does
handle it differently than jsc.exe, although in a different manner than I
had expected: jsc.exe is a managed application, therefore using (I assume)
System.Reflection.Emit and hitting the same limitations you saw, while
csc.exe is an unmanaged app, using whatever it feels like to get the
correct behavior.
At least that's the view from the top level.
At the point where the error occurs however, they both call
STDMETHODIMP IMetaDataEmit::DefineCustomAttribute(...) (not documented
publicly anywhere as far as I could see - but maybe I'm not looking at the
right docs.)
At the lowest level, the error seems to be in a comparison of the fully
qualified attribute name with jsc.exe choking on the comparison of
"SUvSystem.Runtime.InteropServices.CharSet, mscorlib, Version=1.0.3300.0,
Culture=neutral, Public KeyToken=b77a5c561934e089.CharSet"
with
"SUvSystem.Runtime.InteropServices.CharSet"
csc.exe gets the names (and the comparison) correctly.
Now, obviously the more interesting part for you would be at a level a bit
higher than this where the attributes are actually being constructed, but
as I said, this is my first foray in the wondrous world of metadata and
the one hour lunch break is up :)
Cristian
PS. By the way, last time I checked, Rotor was still available for
download, so I was wondering... still concerned about that darn licensing
agreement? ;) I'm sure the code base would make a whole lot more sense to
you than to me.
On Tue, 14 May 2002 17:06:38 -0400, Miguel de Icaza <[EMAIL PROTECTED]>
wrote:
>Hello guys,
>
> We are running into an interesting problem with the Reflection.Emit
>API in Mono, precisely, this code crashes Reflection.Emit when the Mono
>C# compiler compiles it:
>
>[StructLayout(LayoutKind.Explicit,Size=32,CharSet=CharSet.Ansi)]
>struct FloatHack
>{
> [FieldOffset(0)] public float fh_float;
> [FieldOffset(0)] public int fh_int;
>}
>
> I could not understand what was wrong, but it turns out that this
>also happens with the Microsoft Java Script compiler:
>
>C:\>type test.js
>import System;
>import System.Runtime.InteropServices;
>
>public StructLayoutAttribute (LayoutKind.Auto, CharSet=CharSet.Ansi)
>class Hello {
> var x : System.String;
>}
>
>System.Console.WriteLine ("Hello!");
>
>C:\>jsc test.js
>Microsoft (R) JScript .NET Compiler version 7.00.9466
>for Microsoft (R) .NET Framework version 1.00.3705
>Copyright (C) Microsoft Corporation 1996-2001. All rights reserved.
>
>***INTERNAL COMPILER ERROR***
>Microsoft.Vsa.VsaException: InternalCompilerError (0x80133021):
System.ArgumentException: Invalid custom attribute provided: Unrecognized
custom attribute argument: ????.
> at System.Reflection.Emit.TypeBuilder.InternalCreateCustomAttribute
(Int32 tkAssociate, Int32 tkConstructor, Byte[] attr, Module module,
Boolean toDisk)
> at System.Reflection.Emit.CustomAttributeBuilder.CreateCustomAttribute
(ModuleBuilder mod, Int32 tkOwner)
> at Microsoft.JScript.Class.GetTypeBuilderOrEnumBuilder()
> at Microsoft.JScript.Class.TranslateToIL(ILGenerator il, Type rtype)
> at Microsoft.JScript.Block.TranslateToIL(ILGenerator il, Type rtype)
> at Microsoft.JScript.ScriptBlock.TranslateToIL(ILGenerator il, Type
rtype)
> at Microsoft.JScript.ScriptBlock.TranslateToILClass(CompilerGlobals
compilerGlobals)
> at Microsoft.JScript.VsaStaticCode.TranslateToIL()
> at Microsoft.JScript.Vsa.VsaEngine.DoCompile()
> at Microsoft.Vsa.BaseVsaEngine.Compile()
>
>The problem is that Reflection.Emit has no API for me to set the layout
>bits once a type has been created (otherwise, I could create the type,
>then filter out the attribute, and apply the updates). So I am
>convinced that .NET is applying some magic on its own to the type that
>was created for the CharSet property of the StructLayoutAttribute.
>
>My request for help is to get confirmation for someone who has the Rotor
>source code to verify if the class
>System.Runtime.InteropServices.StructLayout and in particular
>System.Runtime.InteropServices.CharSet is handled specially by Rotor
>during a call to TypeBuilder.SetCustomAttributes.
>
>From the stack trace, it looks like it happens in the C-side of things,
>and not in the IL code.
>
>We plan on handling this at the Reflection.Emit/SetCustomAttribute
>level, since there is no other API that would let us customize the type
>without breaking the compiler in fundamental ways.
>
>This is preferable than adding incompatible APIs to
>System.Reflection.Emit.
>
>I just want confirmation on the fact that our System.Reflection will
>have to manually handle some attributes (and of course, if you can list
>them, that would be even better ;-).
>
>Best wishes,
>Miguel.
