I'd prefer to not list the names of other packages in our docs. I get that it's internal/private, but it may appear that we're "endorsing" the package, where I don't think we can really speak to whether this is the right answer for everyone.

Looks like this also appears below.

Sure, I'll strip this from the xmldocs. Was merely traing to retain the rationale for the non-reference checks.

Would sticking things inside a plain // ... code comment still be endorsing? Or should I just go with "for example imported via nuget or entirely self-supplied".

On that same note:
Two Test projects now have a PackageReference to that Required package (to get the required feature working in .NET6). Are those okay?

I'd probably just leave it generic with "... an internally defined custom polyfill attribute with the type name" and call it a day. We don't have to point to a specific implementation.

It may be worth actually putting our own polyfill in place in the test projects to show how you can do it without referencing a whole polyfill package, unless that's a lot of work. We don't have a lot of dependencies that aren't framework.

Okay, removed the mentions and added the custom polyfill in f5346a7

Had to muzzle stylecop slightly to retain the polyfill's original copyright notice & license. If you have a more "structured" process to include third party notices, feel free to tweak that yourself ;)

It would have been nice to maybe create these from scratch instead of copying them out of an existing library. Part of the point is to show folks how to do this without references and without extra licensing.

Well, considering the polyfill is purely functional and has to take that specific shape with those specific class names & preprocessor guards (okay, one could skip the nullable directives and warning toggles) and me knowing where I saw this, whatever I did would always be a "derivative" of a pre-existing version.
And if that's the case I might as well acknowledge where it came from... I'm not too fond of not-invented-here-syndrome, and considering the pre-existing polyfill is MIT licensed.... I'm even less tempted to pretend having done a clean room implementation ;)

@alistairjevans I'll leave this one for you. My thoughts:

• Don't keep the preprocessor directives if we don't need them.
• One class per file, even for the polyfills.
• Possibly make them public rather than internal since they're in the test project anyway.
• It may be arguably fundamentally different enough that it's unique but I'm not sure I care enough to argue it beyond that.

• Possibly make them public rather than internal since they're in the test project anyway.

I'd strongly discourage that. (At least if the polyfill is supposed to stand as an example for how to do this). Imagine the scenario of someone (re)using that example with public attributes. They build a netstandard2 assembly with it. That assembly then gets consumed in a NET7+ project. Suddenly you have duplicate attribute definitions and a lot of compiler barfing.

I'm not fussed about making the shims public; they're defined by the .NET Compiler as internal, so if we're looking to create proper shims, we should do the same. See my other note about them being the 'formal' spec for the attribute.

I would like to be clear though that this polyfill in this test project is absolutely not an example of how to polyfill the required attributes. I'd really hope no-one ends up using an Autofac test project as an example of polyfilling in a distributed library.