When should System.Type be inherited

Question

The documentation for Type.GetTypeCode states:

Remarks

When you inherit from Type, you can change the behavior of this method by overriding the GetTypeCodeImpl method.

The documentation not describe when to inherit from System.Type. Is it even valid or applicable for any real application or is it only for implementers of CLI?

The System.Type documentation doesn't contain this information either, it only has a list of which members must be overridden for derived classes.

As there is no way of overriding typeof, I assume that the typeof operator still return an instance of the internal System.RuntimeType class from the mscorlib assembly, or similar. What use would then a user derived class have?

Answer 1

You shouldn't derive your own type from System.Type, basically. It's not something I can ever see a use for, unless you're part of the CLR team. It's just about possible that if you're implementing a mocking framework or something like that, there could be some reason to do so - but I'm pretty doubtful. I'd be pretty suspicious of anything deriving from Type - I would expect it's the kind of thing which can go wrong fairly easily if you're not careful.

I suspect what the documentation should have said was "classes deriving from System.Type change the behaviour of this method by overriding GetTypeCodeImpl" - although frankly even that is something that users don't really need to know.

Answer 2

In my case, I wanted to create instances and classes I would create on the fly at run time (from a data source ex: XML). I successfully subclassed System.Type but it was useless: you can’t create instances using Activator.CreateInstance(yourSubType).

I got over the problem by converting my source (XML) into compilable c# code and then compile it using CSharpCodeProvider.