Hi there,

Does anyone know if there's a (simple) way to detect whether an arbitrary
"System.Type" originates from the .NET framework opposed to a user-defined
assembly. Thanks.

On Mon, 21 Jul 2008 16:05:20 -0700, John W. <no_spam@_nospam.com> wrote:

> Hi there,
>
> Does anyone know if there's a (simple) way to detect whether an arbitrary
> "System.Type" originates from the .NET framework opposed to a
> user-defined
> assembly. Thanks.

Define ".NET Framework". Do you mean just the CLR? Or do you mean to
include any assembly provided by Microsoft as part of .NET?

I don't know if there's a canonical mechanism for identifying types as
..NET or not, but it shouldn't be too hard to track down the names of all
the assemblies you consider to be part of .NET, and then look at the
System.Type.Assembly property to see if the type in question comes from
one of those assemblies.

Pete

Thanks for the feedback ...

> Define ".NET Framework". Do you mean just the CLR? Or do you mean to
> include any assembly provided by Microsoft as part of .NET?

Yes, the CLR - anything that's installed with the framework installer.

> I don't know if there's a canonical mechanism for identifying types as
> .NET or not

You're probably right. I was hoping there might be a way ...

, but it shouldn't be too hard to track down the names of all
> the assemblies you consider to be part of .NET, and then look at the
> System.Type.Assembly property to see if the type in question comes from
> one of those assemblies.

I was also hoping to avoid this route if possible. My app will be processing
arbitrary types on 2.0 or later and I need to distinguish between
user-defined types and native .NET types. I didn't want to have to track
down all assemblies in 2.0 and 3.X. It would be cleaner if there was a way
to dynamically determine things on-the-fly.

On Mon, 21 Jul 2008 16:40:59 -0700, John W. <no_spam@_nospam.com> wrote:

> Thanks for the feedback ...
>
>> Define ".NET Framework". Do you mean just the CLR? Or do you mean to
>> include any assembly provided by Microsoft as part of .NET?
>
> Yes, the CLR - anything that's installed with the framework installer.

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.

I take your answer to mean _all_ of .NET, not just the CLR (the latter
would be easier...just look for the one DLL).

> [...]
> I was also hoping to avoid this route if possible. My app will be
> processing
> arbitrary types on 2.0 or later and I need to distinguish between
> user-defined types and native .NET types.

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?

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. :)

Pete

> 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 was also hoping to avoid this route if possible. My app will be
>> processing arbitrary types on 2.0 or later and I need to distinguish
>> between
>> user-defined types and native .NET types.
>
> 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.

John W. wrote:
> 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).

> 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.

I don't think you can find a perfect solution.

But here are 2 things that may give a good indication:

If t.FullName starts with System or Microsoft then
it is probably .NET !

If t.Assembly.Location starts with C:\Windows then
it is probably .NET !

Arne

> I don't think you can find a perfect solution.
>
> But here are 2 things that may give a good indication:
>
> If t.FullName starts with System or Microsoft then
> it is probably .NET !
>
> If t.Assembly.Location starts with C:\Windows then
> it is probably .NET !

Thanks for the suggestion. I don't think it will fly unfortunately. It's too
imprecise and therefore subject to failure (anyone can apply "System" or any
other namespace to their type and nothing's stopping them from installing a
3rd-party assembly in the system folder - rare as this might be).

John W. wrote:
>> I don't think you can find a perfect solution.
>>
>> But here are 2 things that may give a good indication:
>>
>> If t.FullName starts with System or Microsoft then
>> it is probably .NET !
>>
>> If t.Assembly.Location starts with C:\Windows then
>> it is probably .NET !
>
> Thanks for the suggestion. I don't think it will fly unfortunately. It's too
> imprecise and therefore subject to failure (anyone can apply "System" or any
> other namespace to their type and nothing's stopping them from installing a
> 3rd-party assembly in the system folder - rare as this might be).

If you want to protect against someone deliberately trying to
trick you, then:
1) you need to have a positive list with assembly names and
cryptographic strong checksums
2) have you considered if people can decompile your app, remove
the check and recompile ?

Arne

On Mon, 21 Jul 2008 18:30:16 -0700, John W. <no_spam@_nospam.com> wrote:

> Thanks for the suggestion. I don't think it will fly unfortunately. It's
> too
> imprecise and therefore subject to failure (anyone can apply "System" or
> any
> other namespace to their type and nothing's stopping them from
> installing a
> 3rd-party assembly in the system folder - rare as this might be).

Well, I think the latter is actually more likely. It seems like a
legitimate installation behavior for certain kinds of software.

But the former seems very unlikely except in the case of willful
impersonation. And if you're concerned about that, then there's not
really anything you can do to avoid someone bypassing your check.

Unfortunately, your unwillingness to describe the problem further makes it
difficult to offer suggestions. If this is a tool to aid the user, I
think that there are things like what Arne suggests as well as just
looking at what the input to the tool is (i.e. types that are part of
assemblies the user doesn't specifically provide to the tool are inferred
to be .NET types). If you're looking for some sort of secure analysis of
the code, then I think the best you can do is build your own "white list"
of .NET assemblies and base the analysis on that. And even in that case,
someone who wants to would be able to hack your tool in order to get it to
produce whatever results _they_ want rather than the results you wanted.

Pete

>> Thanks for the suggestion. I don't think it will fly unfortunately. It's
>> too
>> imprecise and therefore subject to failure (anyone can apply "System" or
>> any
>> other namespace to their type and nothing's stopping them from
>> installing a
>> 3rd-party assembly in the system folder - rare as this might be).
>
> Well, I think the latter is actually more likely. It seems like a
> legitimate installation behavior for certain kinds of software.
>
> But the former seems very unlikely except in the case of willful
> impersonation. And if you're concerned about that, then there's not
> really anything you can do to avoid someone bypassing your check.

The real issue to me is that both techniques are hacks. While the namespace
suggestion would probably work in practice, it's cleaner and safer to rely
on "legitimate" techniques. I do appreciate his suggestions however :)

> Unfortunately, your unwillingness to describe the problem further makes it
> difficult to offer suggestions.

I can't for reasons beyond my control.

> If this is a tool to aid the user, I think that there are things like
> what Arne suggests as well as just looking at what the input to the tool
> is (i.e. types that are part of assemblies the user doesn't specifically
> provide to the tool are inferred to be .NET types).

There's more to the story which is why I can't just use a "process of
elimination" technique. All I really need is a clean way to make the
determination given the "System.Type" itself (or even its assembly-qualified
name).

> If you're looking for some sort of secure analysis of the code, then I
> think the best you can do is build your own "white list" of .NET
> assemblies and base the analysis on that. And even in that case, someone
> who wants to would be able to hack your tool in order to get it to
> produce whatever results _they_ want rather than the results you wanted.

I'm not going to worry about hackers. That's always an issue but my code is
already reasonably secure (very painful to hack anyway).