Due to structure of the step architecture in linker, steps that might optionally pull in new assembly dependencies into the closure currently need to run a global pre-pass over the entire app before we reach MarkStep. This architectural deficiency will have to be fixed at some point, but before we do that, dataflow will also need to run such inefficient global prepass to locate all strings stored into locations marked with DynamicallyAccessedMemebers so that we can potentially add new assemblies into the closure.
We should do whatever is the fastest thing. We could potentially do something as dumb as going over all user strings in the assembly, looking for ones that look like a fully qualified type name (have a comma in it and maybe some other heuristics to trim the list of looked at strings down) and try to open the associated assembly, so that we don't need to actually parse IL.
Plus we need to scan custom attributes if their constructor/setter/field is marked DynamicallyAccessed.
Due to structure of the step architecture in linker, steps that might optionally pull in new assembly dependencies into the closure currently need to run a global pre-pass over the entire app before we reach
MarkStep
. This architectural deficiency will have to be fixed at some point, but before we do that, dataflow will also need to run such inefficient global prepass to locate all strings stored into locations marked withDynamicallyAccessedMemebers
so that we can potentially add new assemblies into the closure.We should do whatever is the fastest thing. We could potentially do something as dumb as going over all user strings in the assembly, looking for ones that look like a fully qualified type name (have a comma in it and maybe some other heuristics to trim the list of looked at strings down) and try to open the associated assembly, so that we don't need to actually parse IL.
Plus we need to scan custom attributes if their constructor/setter/field is marked DynamicallyAccessed.