[...]
Except that there's nothing stopping someone from defining their own
type in the System namespace (or any other Microsoft/.NET namespace).
You can check the namespace, but it's too easy for it to be unreliable.
It may be good enough.
It may not be good enough. Given the exact problem statement, for sure
it's not. Given assumptions one might make about what the OP is really
trying to do, maybe it is.
It is not that common to put classes in System.
Lack of common-ness is no insurance of robustness.
And besides if someone did put custom classes in system, then
I would argue that they knowingly or unknowingly has asked to
get it them treated as framework classes.
You can't make that argument any more than either of us can claim whether
such a solution is or is not good enough for the OP's purposes. There
simply isn't enough detail.
It is not a 100% solution, but it is the only practical close to 100%
solution I can think of.
I already posted a reply earlier today; for some reason it hasn't appeared
on the newsgroup yet (it's possible Microsoft's servers are broken again),
so I've copied it below.
To reiterate my answer: assembly identity is a lot more reliable than
namespace name, and if it suits the OP's needs, it is more effective to
check for the user's assembly than a .NET one (there are heuristics that
could be used to try to identify .NET assemblies, but while they would be
more reliable than simply relying on namespace name, they are still not
100% fool-proof).
If you change the problem, you can come up with all sorts of other
possibilities, including just relying on the namespace. But the OP asked
a specific question, and the namespace is not a reliable way to address
that specific question. Nor, in fact, is there any 100% reliable way to
identify a type as belonging to the .NET Framework, short of keeping a
list of all known .NET Framework assemblies and checking a given type's
assembly against that (and obviously that's a maintenance nightmare).
Pete
----- my original post -----
People,
Somebody have an idea to know if determined Type is from .NET
Framework via reflection ? I need verify this to differ to a simple
class defined by me.
Rather than trying to figure out if the type is from .NET, why not check
to see if the type is from your own assembly?
That would be much more reliable (and easier).
Of course, there is always the question of "why do you want to know?"
Very often, when it _seems_ like reflection holds the solution to one's
problem, it simply mean one is looking at the problem wrong.
Pete
