We've had private (underscore-prefixed) item groups for certain native linker arguments, but we keep having to access them to provide workarounds for various bugs.

At this point we should come up with public item groups, for when we're linking the native executable:

1. General arguments to the native linker.
2. Frameworks to link with.

General arguments

NativeAOT uses the LinkerArg property, which IMHO we shouldn't use because:

• It's a property, and runs into quoting problems, because it's just one value with all the linker arguments.
• It's a property, so it's much harder to manipulate (say you want to remove a linker argument, for whatever reason).
• It's abbreviated, which our (admittedly C#) naming guidelines say we shouldn't do.

Other options:

• LinkerArgument
• LinkerOption
• LinkerFlag
• NativeLinkerArgument (somewhat long?)
• NativeLinkerFlag (slightly less long)
• LdArgument (because the native linker is called ld)

Frameworks

Note: technically this isn't needed, it can be implemented using a general linker argument from above.

NativeAOT doesn't really have an equivalent for frameworks, but it has the NativeLibrary item group to link with static libraries (although it might work with frameworks too).

Once again I think we should pick a different name, mostly because the semantics might get confusing and incorrect between us and NativeAOT.

Other options:

• Framework
• LinkWithFramework
• NativeFramework
• LdFramework (because the native linker is called ld)

It would also support the IsWeak metadata, to specify whether the framework should be linked weakly (-weak_framework ... or not (-framework ...).

Note: this would not work with xcframeworks, since it's meant to be passed directly to the linker as-is.

Note 2: this would include both system frameworks (-framework UIKit) and paths to user frameworks (-F /path/to/myframework.framework -framework myframework)

Note 3: once again, this is only a linker flag, we won't copy any user frameworks to the app bundle later on.