Thanks, that's the same exception I'm seeing.
Well, you've certainly stumbled upon one of the less intuitive areas of AutoFixture. The thing is that the Register method is one of the earliest methods of Fixture, and the semantics surrouding it are a bit vague. What it actually does is that it lets you
specify a function that constructs the instance. The rest of the builder pipeline still runs after the instance has been constructed, which means that AutoProperties are still in play.
In this case it means that although is does use originalFoo, it subsequently attempts to assign values to all writable properties. When it reaches the Parts property, it doesn't know how to create an instance of IEnumerable<FooPart>
because it's an interface.
I admit that the Register method isn't particularly intuitive, and I have several times considered changing the behavior, but since it would be a breaking change, I've been shying away from it so far. Perhaps I should reconsider it once again. It even occasionally
trips me up :)
Until then, you have some options:
First of all, according to the Framework Design Guidelines, collection properties should be read-only. Making the Parts property read-only would solve this particular issue, but not address the underlying issue.
As a more generalized solution, you can use the Customize method like this:
var originalFoo = fixture.Build<Foo>().Without(x => x.Parts).CreateAnonymous();
fixture.Customize<Foo>(ob => ob.WithConstructor(() => originalFoo).OmitAutoProperties());
But here's a more succinct alternative:
var originalFoo = fixture.Freeze<Foo>(ob => ob.Without(x => x.Parts));
The Freeze method is essentally a shortcut method around the CreateAnonymous/Register coding idiom.