The behavior you are seeing looks like a bug. It should be easy to fix in Rotor - a patch can be provided if anybody is interested. You have to wait for the next major release of .NET Framework to get it addressed there though.
IMetaDataEmit is documented in "...\FrameworkSDK\Tools Developers Guide\docs\Metadata Unmanaged API.doc". This file is part of the .NET Framework SDK (download from http://msdn.microsoft.com, or use the copy that comes with Visual Studio 7.0). To answer the other question: The list of attributes that are handled in a special way by the runtime can be found in the "ECMA Partition II: Metadata Definition and Semantics" document, chapter "Attributes Used by the CLI". The most relevant part for this implementation detail of System.Reflection.Emit is subchapter "Pseudo Custom Attributes". -Jan This posting is provided "AS IS" with no warranties, and confers no rights. -----Original Message----- From: Cristian Diaconu [mailto:[EMAIL PROTECTED]] Sent: Sunday, May 19, 2002 8:31 AM To: [EMAIL PROTECTED] Subject: Re: [DOTNET-ROTOR] Help requested by the Mono developers. <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.
