AutoFixture doesn't have any explicit support for this kind of scenario where you want a base customization that you can keep building upon (see below).
The Build<T> method doesn't reset the customization of the object, but it ignores it. The difference is subtle, but had it reset it, a subsequent call to CreateAnonymous<T> would not use the customization, and it does. However, Build<T>
ignores any customization already present because the essense of the Build method is that it's a one-off customization. In other words, the behavior of the Build<T> method ignores the customization by design.
However, here is what you can do: the Customize<T> method takes a single Func<LatentObjectBuilder<T>, ObjectBuilder<T>> as input, so you can explicitly remember the the value and use it to build upon.
Instead of doing this:
fixture.Customize<Foo>(ob => ob
.Without(f => f.Bar)
.Without(f => f.Baz));
You can do this:
Func<LatentObjectBuilder<Foo>, ObjectBuilder<Foo>> builderTransform = ob => ob
.Without(f => f.Bar)
.Without(f => f.Baz);
A normal call to CreateAnonymous<Foo> will return a Foo instance without the Bar and Baz properties assigned, but you can use the builderTransform as a basis for further customizations:
fixture.Customize<Foo>(ob => builderTransform(ob)
.With(f => f.Baz)
.Without(f => f.Ploeh));
With this extended customization, a subsequent call to CreateAnonymous<Foo> will now return a Foo instance without the Bar and Ploeh properties, but with the Baz property.
If you'd like, you can expand this approach to remember customization Funcs for all types in a dictionary.
On a closing note, I'd like to ask why you want to do this? However, from your question, I think I can venture a guess: you are using the Entity Framework and need to switch off a lot of the auto-generated properties because many of them have circular references.
When you have an externally defined API like this, there's really not a lot else you can do. However, if you
do have control over the API in question, I would suggest that you rethink the design.
Since AutoFixture is a heuristic, convention-based engine, it has to follow the 80-20 rule to some extent. For a properly designed API, customizations of customizations shouldn't be necessary, so we currently don't have any specific plans to support it.
However, I ask about your scenario out of genuine interest, because if it turns out that there's a reasonable scenario for this, we may have to rethink our strategy on this topic.
In any case, although we have no explicit plans to support customizations of customizations even in AutoFixture 2.0, the next version will sport a much more extensible engine. I haven't thought this completely through, but I think with that engine it would
be possible to write a heuristic add-in for, say, EF that disables AutoProperties for all the problematic properties defined by EF (such as EntityKey, EntityState and all the circular referential navigation properties).