All due respect, that's an inconsistent answer. The CLR is just the
run-time (mscorlib.dll). The .NET Framework includes more than that.
Different parts of .NET are found in different assemblies.
My mistake then. It was my understanding that the CLR consisted of all
assemblies installed with the framework (not just "mscrolib.dll")
I'm curious as to why, if you don't mind sharing. It seems to me to be a
somewhat arbitrary requirement, since the types would otherwise behave
exactly the same. What is it about .NET types versus third-party types
that makes them so different that you need to track them independently?
Unfortunately I can't get specific right now.What I can say is that I'm
working on a tool that will be processing Visual Studio solutions. As a
result, I'm processing a lot of arbitrary types originating from source code
itself. I therefore have a (legitimate) need to distinguish between native
..NET types and types created by the solution's developers (including
3rd-party types).
I don't know. Maybe someone else will have better advice as to how to
identify all of the types that come from .NET, or alternatively how to
automatically determine a complete list of the assemblies that make up
.NET (I figure that would be a reasonable alternative). But on the face
of it, if it were me, I'd be working to redefine the problem so that it's
easier.
The problem can't be "redfined" unfortunately. It's a very specific and
unique requirement which would become clear if I could say more about it.
Note that the object browser in VS itself allows you to browse the ".NET
Framework" assemblies so I'd be interesed in knowing how they're doing it.
It's too bad that "System.Type" itself doesn't provide some property or
method similar to "IsPrimitive" for instance. I can see an "IsNative" or
"IsFramework" property for example.