Greetings,
I'm just curious, but there's something I've noticed about certain CIL-based functionality that Red Gate .NET Reflector seems to imply that languages implement it.
Here's a small example:
.method public hidebysig specialname static class [mscorlib]System.Reflection.MethodInfo testProcedure() cil managed
{
.maxstack 1
L_0000: ldtoken class [mscorlib]System.Reflection.MethodInfo TestExtension.TestPropertyExtension::testProcedure()
L_0005: call class [mscorlib]System.Reflection.MethodBase [mscorlib]System.Reflection.MethodBase::GetMethodFromHandle(valuetype [mscorlib]System.RuntimeMethodHandle)
L_000a: castclass [mscorlib]System.Reflection.MethodInfo
L_000f: ret
}
A nice feature, that the CLI core language CIL allows, is the ability to obtain the runtime method handle of any method (or field, or others I won't mention here), period. This is useful for often unmentioned functionality for .NET languages to support other more robust functionality. An example being C♯'s array initialization, which involves loading the runtime field handle of a private scope field, which is typed to a structure with explicit size information associated to it, and initialized to a value at a data location (via .data cil I_000020D0 = bytearray (...).
The current version of .NET reflector even gives the invalid functionality a name, in C♯ it uses methodof and in VB it uses GetMethod, I can't vouch for the validity in other languages as I don't use any others.
I think it would be more appropriate for the reflector to emit a comment on the line affected with the invalid code, with an addendum stating that it's not functionally a part of the language.
Additionally, I'm not sure of when the functionality was introduced; however, when emitting a project directly to Common Intermediate Language (displayed as IL in Red Gate's .NET Reflector), properties are properly pointed to the method signature that implements the internal aspect of the property; however, their internal code is omitted from the export, thus resulting in code that you cannot use, because the property code isn't exported. This issue is also apparent when viewing the root node of a class or struct type with properties and clicking "Expand Methods".
Further, I noticed when using 'Export' (via the context menu of an assembly node in the left tree-view), IL-based projects do not have any 'project' emitted, although it mentions in the export status that one is. While this isn't a large issue, there's also no continuity provided in the files for the IL-based projects. Perhaps a small build.bat would be beneficial for users of the program (on windows systems, at least). For actually linking the various files, you could use the oft-empty Global.il and a series of #include directives.
Also I'm not sure of the exact reasons, but the global.il emits a class named <Module> which is where most private implementation details are kept. I'm not sure of the specific reason, but I get compile errors when attempting to use it, I'm guessing it's because you're including the braces for the null namespace the <Module> class resides in, or the fact that you're not back quoting the class' name. I'll leave this for you to figure out.
I also haven't done enough tests to be sure, but named .data locations aren't visible in the tree view, does the current export functionality properly export the .data, even though the tree doesn't display it?
Thanks,
I'm just curious, but there's something I've noticed about certain CIL-based functionality that Red Gate .NET Reflector seems to imply that languages implement it.
Here's a small example:
.method public hidebysig specialname static class [mscorlib]System.Reflection.MethodInfo testProcedure() cil managed { .maxstack 1 L_0000: ldtoken class [mscorlib]System.Reflection.MethodInfo TestExtension.TestPropertyExtension::testProcedure() L_0005: call class [mscorlib]System.Reflection.MethodBase [mscorlib]System.Reflection.MethodBase::GetMethodFromHandle(valuetype [mscorlib]System.RuntimeMethodHandle) L_000a: castclass [mscorlib]System.Reflection.MethodInfo L_000f: ret }A nice feature, that the CLI core language CIL allows, is the ability to obtain the runtime method handle of any method (or field, or others I won't mention here), period. This is useful for often unmentioned functionality for .NET languages to support other more robust functionality. An example being C♯'s array initialization, which involves loading the runtime field handle of a private scope field, which is typed to a structure with explicit size information associated to it, and initialized to a value at a data location (via .data cil I_000020D0 = bytearray (...).
The current version of .NET reflector even gives the invalid functionality a name, in C♯ it uses methodof and in VB it uses GetMethod, I can't vouch for the validity in other languages as I don't use any others.
I think it would be more appropriate for the reflector to emit a comment on the line affected with the invalid code, with an addendum stating that it's not functionally a part of the language.
Additionally, I'm not sure of when the functionality was introduced; however, when emitting a project directly to Common Intermediate Language (displayed as IL in Red Gate's .NET Reflector), properties are properly pointed to the method signature that implements the internal aspect of the property; however, their internal code is omitted from the export, thus resulting in code that you cannot use, because the property code isn't exported. This issue is also apparent when viewing the root node of a class or struct type with properties and clicking "Expand Methods".
Further, I noticed when using 'Export' (via the context menu of an assembly node in the left tree-view), IL-based projects do not have any 'project' emitted, although it mentions in the export status that one is. While this isn't a large issue, there's also no continuity provided in the files for the IL-based projects. Perhaps a small build.bat would be beneficial for users of the program (on windows systems, at least). For actually linking the various files, you could use the oft-empty Global.il and a series of #include directives.
Also I'm not sure of the exact reasons, but the global.il emits a class named <Module> which is where most private implementation details are kept. I'm not sure of the specific reason, but I get compile errors when attempting to use it, I'm guessing it's because you're including the braces for the null namespace the <Module> class resides in, or the fact that you're not back quoting the class' name. I'll leave this for you to figure out.
I also haven't done enough tests to be sure, but named .data locations aren't visible in the tree view, does the current export functionality properly export the .data, even though the tree doesn't display it?
Thanks,