B
Ben Blair
Hi All,
I'm looking for a way to cause type instantiation to call
a custom class factory instead of having the CLR create an
instance of the type on its own. Specifically, I need to
return a subclass instance when a new base class instance
is requested.
A simple class factory pattern would seem to work, except
that I need this to work with existing code that uses
the 'new' operator. I've got a library that can
automatically generate subclasses of existing classes but
with embedded monitoring code (and some other features).
Ideally, an existing application could use this simply by
making a small change in their runtime environment.
Requiring minor code changes in the application, such as
registering some event handlers on startup would be
acceptable. Requiring a user to replace all
MyClass a = new MyClass();
with
MyClass a = AClassFactory.CreateInstance();
is not acceptable. Not only would that require the
developer to make extensive changes, but it would require
them to know ahead of time which classes they wanted to
instrument and which they didn't. I feel pretty strongly
that there needs to be a way to (easily and automatically)
instrument any non-sealed class.
I have a couple of almost-solutions but none of them quite
work.
1) The AppDomain could support an event much like
TypeResolve except that it allows the event handler to
return a Type object rather than an Assembly object. I
can't find such an event and I can't figure out how to use
TypeResolve to accomplish the same thing, although it
might be possible. Also, TypeResolve only fires when the
CLR can't resolve the type on its own, instead of always.
Is there a way to trick TypeResolve into always firing?
2) Override the new operator. But this isn't allowed.
3) Create a subclass of Type that overrides
CreateInstance, GetConstructor, etc. I can't figure out
how to get the CLR to use this type object instead of the
base-class's type object. Also, this could have lots of
unintended consequences. But at the moment, it seems like
the only thing that might work.
4) Bend my rule a little bit and only support
instrumenting of objects created with
Activator.CreateInstance(). This is kind of ugly, but at
least it would keep the developer free to decide later
what to instrument if *all* uses of 'new' were replaced
with Activator.CreateInstance().
Any ideas or suggestions? Thanks.
- Ben Blair
- benblair@ Association for Computing Machinery dot org
I'm looking for a way to cause type instantiation to call
a custom class factory instead of having the CLR create an
instance of the type on its own. Specifically, I need to
return a subclass instance when a new base class instance
is requested.
A simple class factory pattern would seem to work, except
that I need this to work with existing code that uses
the 'new' operator. I've got a library that can
automatically generate subclasses of existing classes but
with embedded monitoring code (and some other features).
Ideally, an existing application could use this simply by
making a small change in their runtime environment.
Requiring minor code changes in the application, such as
registering some event handlers on startup would be
acceptable. Requiring a user to replace all
MyClass a = new MyClass();
with
MyClass a = AClassFactory.CreateInstance();
is not acceptable. Not only would that require the
developer to make extensive changes, but it would require
them to know ahead of time which classes they wanted to
instrument and which they didn't. I feel pretty strongly
that there needs to be a way to (easily and automatically)
instrument any non-sealed class.
I have a couple of almost-solutions but none of them quite
work.
1) The AppDomain could support an event much like
TypeResolve except that it allows the event handler to
return a Type object rather than an Assembly object. I
can't find such an event and I can't figure out how to use
TypeResolve to accomplish the same thing, although it
might be possible. Also, TypeResolve only fires when the
CLR can't resolve the type on its own, instead of always.
Is there a way to trick TypeResolve into always firing?
2) Override the new operator. But this isn't allowed.
3) Create a subclass of Type that overrides
CreateInstance, GetConstructor, etc. I can't figure out
how to get the CLR to use this type object instead of the
base-class's type object. Also, this could have lots of
unintended consequences. But at the moment, it seems like
the only thing that might work.
4) Bend my rule a little bit and only support
instrumenting of objects created with
Activator.CreateInstance(). This is kind of ugly, but at
least it would keep the developer free to decide later
what to instrument if *all* uses of 'new' were replaced
with Activator.CreateInstance().
Any ideas or suggestions? Thanks.
- Ben Blair
- benblair@ Association for Computing Machinery dot org