Closed pallavit closed 4 years ago
We've reviewed this proposal and approved the direction. I've marked it as "in progress", because still want to review the effect surface area being added. Specifically, there are some open issues:
System.Reflection.Extensions
and System.Reflection.TypeExtensions
.Binder
System.Reflection.TypeExtensions
Binder
Binder
Type
, are also on TypeInfo
@pallavit, I'll remove the 'api-ready-for-review' label. Once we've a complete diff, please copy & paste the unified diff in your description above and add the 'api-ready-for-review' label. Thanks!
@pallavit Does closing dotnet/runtime#15689 mean we'll bring back TargetException
?
@terrajobst In the review, we decided to expose the type. Do you have any concerns with the decision?
Nope. Was just asking because I didn't remember talking about this. Will add this to the notes.
Notes are now available.
Considering we're all on the same page now and the only thing pending is the dev work, I've marked the change as approved.
The following PRs expose the APIs reviewed for System.Reflection. Please let me know if you see any issue consuming them. (#6557, dotnet/corefx#6754, dotnet/corefx#6808 , dotnet/corefx#6815, dotnet/corefx#6870).
Is there a particular reason ExceptionHandlingClause
was removed? We consume it in Sigil
(one of our IL utility libraries).
Found this by accident.
Assembly.EscapedCodeBase is something we've had to depend on for its ability to locate the real assembly directory when hosted by IIS, while the normal path function returns something stupid (IIS scratch directory).
What about MemberInfo.ReflectedType
? I'm unable to find it.
Are DynamicILInfo
and MethodBody
ever coming back? If not, what alternatives are there for someone trying to port to .NET Core and relying on these types?
Found when writing tests for System.Linq.Expressions
to assert generated IL code: the Resolve
methods on Module
are missing.
+1 for the Resolve
members: I was trying to do the following in PR dotnet/corefx#11417 to reproduce a bug and demonstrate a test, but the APIs weren't exposed on .NET core
AssemblyBuilder assembly = AssemblyBuilder.DefineDynamicAssembly(new AssemblyName("Name"), AssemblyBuilderAccess.Run);
ModuleBuilder module = assembly.DefineDynamicModule("Name");
MethodBuilder builder = module.DefineGlobalMethod(".cctor", MethodAttributes.RTSpecialName | MethodAttributes.SpecialName | MethodAttributes.Static, typeof(void), new Type[0]);
builder.GetILGenerator().Emit(OpCodes.Ret);
int token = builder.GetToken().Token;
module.CreateGlobalFunctions();
ConstructorInfo constructor = (ConstructorInfo)module.ResolveMember(token);
Console.WriteLine(constructor.Name);
Is there a rationale for removing / replacement for using MethodBase.GetMethodBody()
(or rather, MethodBody.GetILAsByteArray()
which is my ultimate target). Used in a couple places in Jil, and it's not trivial to work around it's absence.
@kevin-montrose As far as I can tell, both [MethodBase.GetMethodBody()
](https://apisof.net/catalog/System.Reflection.MethodBase.GetMethodBody()) and [MethodBody.GetILAsByteArray()
](https://apisof.net/catalog/System.Reflection.MethodBody.GetILAsByteArray()) are planned for .Net Standard 2.0 and .Net Core 1.2.
Hey! IsSubclassOf was removed. What can use to same result?
@bits8 Type.IsSubclassOf
is coming back in .Net Core 2.0 and .Net Standard 2.0. In the meantime, one option would be to copy its source code.
If you make an extension method matching the signature, then the compiler will switch to using the instance method instead as soon as it becomes available.
@bits8 This should serve:
internal static class TypeExtensions
{
public static bool IsSubclassOf(this Type p, Type c)
{
// Don't leave this null-check out, or you could have silent errors
// that suddenly break when the instance method comes back.
if (p == null)
{
throw new ArgumentNullException(nameof(p));
}
if (p == c)
return false;
while (p != null)
{
if (p == c)
return true;
p = p.BaseType;
}
return false;
}
}
@svick @JonHanna Thank you! I've solved this issue with writing own code.
@JonHanna
Hey, I'm having an issue where it seems like BaseType
is not defined?
'Type' does not contain a definition for 'BaseType' and no extension method 'BaseType' accepting a first argument of type 'Type' could be found (are you missing a using directive or an assembly reference?)
Is this right, or am I doing something wrong?
This is a blanket issue to review gaps in System.Reflection namespace in .NetCore vs Desktop
Proposed additions to .NET Core
Notes