Consider adding AllowRejection to formalize rejection

Specifying AllowDefault on an import allows us to still instantiate the part being composed if that import is not found.

It would be useful to express the current semantics of rejection if AllowDefault is missing, but without causing an error in the composition. This would formalize the implicit expectation that the part will get rejected if the import is missing.

The big problem with rejection is it can have unforeseen consequences as it’s transitive. Also having errors in the composition is not great.

The Roslyn team has a usage scenario that goes like this:

We have [Export] components with required imports, knowing that in some scenarios the import will not be available and the linked export will silently also not be part of the catalog. We are using this to simulate a behavior where a MEF export in package A behaves as though it was provided by package B, where package A is always available but package B is optional. By implementing the export in package A with a required import from package B, the export becomes fully-conditioned on B.

Currently this scenario causes by-design errors in the composition. So hosts that rely on composition errors for diagnostics and investigation of real failures now get to either filter the by-design errors or manually filter the types that will get rejected in their composition.

I’m guessing one thing we can do is add

[Import(AllowRejection = true)]

or

[Import(RejectIfMissing = true)]

or

[Import(CausesRejectionIfMissing = true)]

and don’t report an error in the composition if the part is rejected.

See some discussion here: https://github.com/dotnet/roslyn/pull/42121

[AArnott]

We’ll leave this active for now, but the extensibility team is booked through half of 16.7 already, so I don’t see this happening any time soon. If you’re willing to send the PR yourself, I can write a mini-spec for what I’d like to see and am willing to review it.

CC: @tinaschrepfer

[AArnott]

VS-MEF doesn’t define its own attributes, so we can’t do any of your suggestions.

I’m also concerned that folks might expect a behavioral change by setting something like AllowRejection=true when in fact rejection is always the behavior when a MEF part’s imports can’t be satisfied.

We could perhaps define a new attribute called [RejectionExpected] or something like that, that might be placed on the [Import] member or perhaps on the MEF part itself. I believe the only effect you want this to have is to designate it differently in the MEF composition log.

We would still need to record in the log that the part was rejected, since folks who want to know why it’s missing would still need to find the evidence, so all we’re talking about (I think) is adding an annotation to that log entry stating that rejection of this part might be expected.