Comment by jve

2 hours ago

> If you're just trying to handle them with reflection none of this is an issue

But maybe indicates on how expensive that reflection call can be? Reading multiple .dlls ?

3 comments

jve

Reply
EMM_386  26 minutes ago

Be careful with this sort of logic ("reflection=expensive").

Everything should obviously be measured.

I've worked with large .NET code bases that used attributes for things like plugins and it was completely negligible for overall performance in the grand scheme of things.

Rohansi  1 hour ago

.NET typically loads dozens of DLLs at boot. It needs to resolve references for almost everything before it can run any code. It doesn't take that long to boot so I have my doubts but they have surely optimized it a lot there.

pjc50  2 hours ago

I would expect DLL parsing to be a one-off cost at assembly load time. Certainly that handles all the stuff detailed under "Assembly resolution". Assembly resolution is also recursive, so I would expect that to simplify "type tree traversal" by pre-stuffing all the types into a Dictionary.

That also necessarily has the parser for all the "System.Int32, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" machinery.

>> "While C# does not support types with weird symbols, it is possible to have type names with spaces, commas, brackets, unprintable characters, and more. This is also heavily (ab)used by code obfuscators."

.. hmm. I didn't know that.

I will note that there is a milder version of this problem which you might encounter if you're trying to write a dotnet source generator, which is run inside the Roslyn compiler. You then need to remember that the types in the code being compiled are not directly visible from reflection, you have to ask the compiler to look them up for you in the parsed data.

These cases are easy:

    - types in the netstandard2.0 standard library
    - types in the assembly currently being compiled

This case is not:

    - types in assemblies in the same project which the current assembly depends on

I ended up avoiding handling that at all. It does set some limits on what is easily done with source generators.

(by the way, someone sufficiently dedicated should be able to find the corresponding Microsoft loader code: it's all in the dotnet github)