This blog post seems to claim that this was quite possible at some point: https://www.jimmybogard.com/integration-testing-with-xunit/ (section: "Class Fixture Design"):

public class MyTestClass_For_Some_Context
    : IClassFixture<MyTestClass_For_Some_Context.Fixture> {
    private readonly Fixture _fixture;
    public MyTestClass_For_Some_Context(Fixture fixture)
        => _fixture = fixture;
    
    [Collection(nameof(SharedFixture)]
    public class Fixture : IAsyncLifetime {
        private readonly SharedFixture _sharedFixture;
        public Fixture(SharedFixture sharedFixture)
            => _sharedFixture = sharedFixture;

        public async Task InitializeAsync() {
            // Arrange, Act
        }
        public Order Order { get; set; }
        public OtherContext Context { get; set; }
        // no need for DisposeAsync
    }

    [Fact]
    public void Should_have_one_behavior() {
       // Assert
    }

    [Fact]
    public void Should_have_other_behavior() {
       // Assert
    }
}

However, I can't seem to get this pattern to work even in older versions -- it always yields an error of the form:

   System.AggregateException : One or more errors occurred. (Class fixture type 'FixtureTest.Fixture' had one or more unresolved constructor arguments: SharedFixture sharedFixture) (The following constructor parameters did not have matching fixture data: Fixture fixture)
---- Class fixture type 'FixtureTest.Fixture' had one or more unresolved constructor arguments: SharedFixture sharedFixture
---- The following constructor parameters did not have matching fixture data: Fixture fixture

@DalekBaldwin Your example code here seems wrong (and is missing important code; namely, the definition of SharedFixture).

The class Fixture is incorrectly decorated with [Collection]. That's intended to be decorated onto your test class to indicate which collection the tests in that class are in.

In addition, you need a collection definition class to indicate which collection fixture(s) are available to tests in the collection.

I recommend you look at my example below for the correct structuring of the classes involved. Fixture1 is the fixture that's applied at the collection level, and Fixture2 is the fixture that's applied at the class level, that accepts the instance of Fixture1 via constructor argument. The mappings to your sample, I think, would be Fixture1 => SharedFixture, Fixture2 => Fixture.