Two different things are going on here, and none of them are easily 'fixed'. I'll keep them both in mind for version 3.0 of AutoFixture (which is on the drawing board), but as far as I can tell right now, addressing them will introduce breaking changes.
Here's some more explanation:
1. The first case is an example of the behavior I explained earlier, and while I accept that it's a POLA violation, I'm having a hard time figuring out how to fix it.
The issue is this: the core AutoFixture library knows nothing about Moq. This is a very deliberate design decision because anyone should be able to pick up AutoFixture without feeling that a certain framework (like Moq) is being forced upon them.
Thus, all the knowledge about Moq is encapsulated in the AutoMoqCustomization class. If there's an issue with how that extension treats various Moq classes, it can be addressed there.
However, when you invoke the Build method, you deliberately leave behind all the Customizations in order to assert fine-grained control over the specific specimen you want to create. You're basically saying that you don't want to rely on the algorithms encapsulated
in the Fixture instance (including the customizations), but instead you want to take control yourself. The Build method is there in order to give you (close to) total control when you need it, but in most cases, you shouldn't need it.
All this means is that all of AutoFixture's understanding about Moq is lost within the Build method chain. What is required in order to arrive at the behavior you would like is to either turn off auto-properties with the OmitAutoProperties method, or add
special treatment for the DefaultValue enumeration. However, since the DefaultValue enumeration is a Moq-specific type, this special treatment can't be build into the core of AutoFixture. It could be implemented in the extension, but this is lost when you
invoke the Build method.
Consider using the Build method less - personally, I hardly ever use it. What's your reason for using the Build method in this scenario?
2. This is a completely different issue which is discussed here:
http://autofixture.codeplex.com/workitem/4245 Basically, AutoMoqCustomization doesn't use AutoProperties.