Assembly.GetTypes - why use this if GetExportedTypes is available?

I am confused by what scenarios you would use one or the other.

If you have an assembly with some public and private (or internal) types, then only public types should be accessible from the outside. Any types that are internal or private should not be accessible; in fact, their existence should not be detectable.

Therefore, GetTypes and GetExportedTypes - in my opinion, should return the same.

It’s clear that I think about it wrong - what is each of them for?

Thanks!

+7
source share
6 answers

Visibility at the language level has nothing to do with visibility at the reflection level.

The whole idea of ​​thinking is that you can see all types, members, etc. and check them out; let's say for the purpose of generating code or something else. Similarly, you have scripts, for example, when using InternalsVisibleToAttribute and, as others have said, when you need to mirror your own assembly. All of them are completely legal and will be impossible (thereby severely restricting the .Net infrastructure) if they are not available.

Therefore, by default, all types should be returned - only when trying to use the type at runtime makes visibility available. It can also be stepped; the .Net infrastructure itself relies on some scenarios in which you can create instances of other native assembly types; and you can also skip visibility checks on your own dynamically built assemblies. I use this feature in my own IOC and DI applications written for our internal applications so that our developers can completely hide types from external code, but can still be used in their applications.

+4
source

From MSDN Docs :

Assembly.GetTypes Method
Return Value Type: System.Type []
An array containing all types defined in this assembly.

From MSDN Docs :

Assembly.GetExportedTypes Method
Return value
Type: System.Type []
An array that represents the types defined in this assembly that are visible outside the assembly.

That way, calling GetTypes() will really give you the all types defined in the assembly, whether they are “visible” and available to you or not. It may seem strange - but what if you want to test yourself, your own assembly (or an assembly in the same namespace as your code)? You should be able to see everything - if necessary.

+6
source

For external assemblies that would really take place, but what if you call GetTypes on your own assembly?

Then you will also see private and internal, which is logical.

0
source

GetExportedTypes() does not include protected / private types. GetTypes() includes all types.

As for internal , the MSDN documentation GetExportedTypes() is unclear.

0
source

If you need all the public types, you can use GetExportedTypes, but if you want to use all the other types, you can use GetTypes. Even if the type is private or internal, you can create new instances and use it through Reflection and Dynamic, so I don’t see any of them being redundant.

0
source

I studied the web API error that ran into this and found one very important difference between Assembly.GetExportedTypes and 'Assembly.GetTypes`. It is in the documentation but not very clear.

Assembly.GetExportedTypes throws a "FileNotFoundException" if any of the dependent assemblies cannot be loaded. "Assembly.GetTypes throws ReflectionTypeLoadException which contains types that are loaded successfully. So, if you want to succeed even if some of the types in the assembly cannot be loaded, you should use GetTypes and not GetExportedTypes`.

This piece of code does not work because Assembly.GetExportedTypes does not throw a ReflectionTypeLoadException .

  Type[] types; try { types = assembly.GetExportedTypes(); } catch (ReflectionTypeLoadException e) { types = e.Types; } 
0
source

All Articles