Add back most CreateInstance APIs to AppDomain and Activator #26413
Description
I've encountered a ton of desktop code that uses either
AppDomain.CreateInstance(string, string)
AppDomain.CreateInstanceFrom(string, string)
AppDomain.CreateInstanceAndUnwrap(string, string)
AppDomain.CreateInstanceFromAndUnwrap(string, string)
And similar APIs on Activator.
I know these APIs were in support of remoting, but they are just too attractive since they deal in strings and folks can easily use them dynamic type loading (rather than first getting a type and then creating an instance from that). Given that we've added back MarshalByRefObject I don't see any reason why we shouldn't just add back these APIs and make them work in the non-remoting case. It'll save a lot of paper-cut type porting.
update 6/28/2018
Actual API
namespace System {
// Add to System.Runtime.Extensions contract & implementation
public partial sealed class AppDomain {
public ObjectHandle CreateInstance(string assemblyName, string typeName);
public ObjectHandle CreateInstance(string assemblyName, string typeName, bool ignoreCase, BindingFlags bindingAttr, Binder binder, object[] args, CultureInfo culture, object[] activationAttributes);
public ObjectHandle CreateInstance(string assemblyName, string typeName, object[] activationAttributes);
public object CreateInstanceAndUnwrap(string assemblyName, string typeName);
public object CreateInstanceAndUnwrap(string assemblyName, string typeName, bool ignoreCase, BindingFlags bindingAttr, Binder binder, object[] args, CultureInfo culture, object[] activationAttributes);
public object CreateInstanceAndUnwrap(string assemblyName, string typeName, object[] activationAttributes);
public ObjectHandle CreateInstanceFrom(string assemblyFile, string typeName);
public ObjectHandle CreateInstanceFrom(string assemblyFile, string typeName, bool ignoreCase, BindingFlags bindingAttr, Binder binder, object[] args, CultureInfo culture, object[] activationAttributes);
public ObjectHandle CreateInstanceFrom(string assemblyFile, string typeName, object[] activationAttributes);
public object CreateInstanceFromAndUnwrap(string assemblyName, string typeName);
public object CreateInstanceFromAndUnwrap(string assemblyFile, string typeName, bool ignoreCase, BindingFlags bindingAttr, Binder binder, object[] args, CultureInfo culture, object[] activationAttributes);
public object CreateInstanceFromAndUnwrap(string assemblyName, string typeName, object[] activationAttributes);
}
// Add to System.Runtime contract, System.Private.CoreLib implementation
public partial sealed class Activator {
public static ObjectHandle CreateInstance(string assemblyName, string typeName);
public static ObjectHandle CreateInstance(string assemblyName, string typeName, bool ignoreCase, BindingFlags bindingAttr, Binder binder, object[] args, CultureInfo culture, object[] activationAttributes);
public static ObjectHandle CreateInstance(string assemblyName, string typeName, object[] activationAttributes);
public static ObjectHandle CreateInstanceFrom(string assemblyFile, string typeName);
public static ObjectHandle CreateInstanceFrom(string assemblyFile, string typeName, bool ignoreCase, BindingFlags bindingAttr, Binder binder, object[] args, CultureInfo culture, object[] activationAttributes);
public static ObjectHandle CreateInstanceFrom(string assemblyFile, string typeName, object[] activationAttributes);
}
}
// Add to System.Runtime contract, System.Private.CoreLib implementation since its needed by Activator
namespace System.Runtime.Remoting
{
public class ObjectHandle : MarshalByRefObject {
public ObjectHandle(object o);
public object Unwrap();
}
}Noted omissions and reasons:
- Overloads that accept
System.Security.Policy.Evidence- Evidence type lives in System.Security.Permissions and is a stub type. We wouldn't want to push this down into System.Runtime where Activator lives but would need to since these are statics that cannot be replaced with extension methods.
- Low usage data, but non-zero. Its possible folks may need this but lets wait for the specific use case, since this is costly and may require other complementary API for a scenario to work.
- Overloads on
System.Activatorthat acceptSystem.AppDomain- Would require pushing AppDomain into System.Runtime
- Zero usage data
System.Runtime.Remoting.IObjectHandleonObjectHandle- Not required for any scenario
- Zero usage data