Consider marking linked assemblies on the output

[vitek-karas]

As far as I can tell linker doesn't mark the assemblies which it linked (as in changed) in any way. Some tools might want to detect linked applications to avoid problems with missing APIs. One such example is the startup hook feature.

One such mechanism could be to inject an assembly level attribute, something like:

[assembly: AssemblyMetadata("ILLinkProcessed", "True")]

Size impact of such change should be trivial.

[marek-safar]

What would this attribute mean? ILLinker has several modes of how to process assemblies as some of them don't really modify the content.

[vitek-karas]

We could have a metadata value which indicates that linker removed some parts (when we do actual Sweep step on it). And then we could have a different value for cases where we do rewrite the assembly but we don't intentionally remove anything (so it goes through Cecil read->write roundtrip, but we don't sweep).

The scenario is above mentioned cases where something tries to load a "plugin" into potentially linked app. Currently there's no indication that the app is linked and so it seems as if it's safe to load the plugin. In reality linked apps are likely not suitable for plugin loading and it should not be attempted (as the code may fail in unexpected ways or change behavior).

[marek-safar]

We could go with

[assembly: AssemblyMetadata("ILLinkProcessed", "link")] // storing the ACTION on the assembly (except for skip)

The question remains what to do when the assembly is processed multiple times with different modes (e.g. link first then copy)

[vitek-karas]

I think we will need a way to disable the marking - for cases like our own build of libraries. We do "link" the assemblies in that step, but we work hard to make sure that doesn't break anything. Or rather, we should definitely not ship all assemblies in the framework marked as "link' - that would defeat the purpose.

We could read the attribute which is already there and only make it "more strict" (so copy->link but not the other way round).

[samsp-msft]

I think this should be about modification rather than linking. What if it was a counter of how many times it had been morphed, and if a tool morphs it in any way, then the counter would be incremented.

The other question is whether there should be some form of report from the linker to say what has been trimmed, and possibly what the roots are for each member that kept it?

[vitek-karas]

The other question is whether there should be some form of report from the linker to say what has been trimmed, and possibly what the roots are for each member that kept it?

Linker can already produce a report which describes the root for everything it keeps. It doesn't have a report for things which were removed though.

[richlander]

What is the scenario in which maintaining a counter inside the assembly would be useful, @samsp-msft? The roots might better be recorded in a PDB.

[samsp-msft]

The reason I suggested a counter is that conversation further up indicated that multiple tools may have modified the assembly. What you want to know is has it been modified (could possibly be done by checking file size, but a counter is an alternative.

[richlander]

What's the code you would write at the very end to take advantage of that counter?

[gjuttla]

The other question is whether there should be some form of report from the linker to say what has been trimmed, and possibly what the roots are for each member that kept it?

The more general case (the information whether an assembly was trimmed) would be very useful for CLR profilers.

Trimmed assemblies present a challenge for a CLR profiler which performs instrumentation (IL rewriting, metadata changes) because there is no guarantee about the existence of types anymore. One safety net would be to disable instrumentation completely if a trimmed assembly is detected.

Maybe just by adding a custom attribute on the assembly?

[marek-safar]

Trimmed assemblies present a challenge for a CLR profiler which performs instrumentation (IL rewriting, metadata changes) because there is no guarantee about the existence of types anymore.

I don't understand this comment. Could you describe the scenario in more details?

[gjuttla]

The .NET component of our monitoring solution is a CLR profiler. We inject our code into our customers' applications at runtime. This includes adding new references to types and assemblies. Now with trimmed assemblies, the situation arises where we are injecting code with references to types and assemblies which have been trimmed from the customer's application and therefore cannot be resolved.

With an annotation on the assembly indicating that a certain assembly was trimmed, we could skip the modification of the assembly at all and prevent possible crashes.