Does not work for ICollection namespace, is this true?

[jeffward01]

Hello!

I noticed that this does not work for collections, is this true?

Thanks for the cool library!

[MelGrubb]

In the new v2.0 version, I've moved away from marking the target classes with GenerateBuilder and moved to marking a partial builder class with a BuilderFor attribute. This means that you can place the builders anywhere you want. It also means that since the builders copy the using block from your half of the partial, you have a way to get around these kind of namespace problems. Whatever you use in your half gets used in the generated half. Also, the generated half should be using fully-qualified names for everything it touches anyway. If the problem still remains, could you provide me with an example?

One problem with an interface though is that the builder can't possibly instantiate an interface, so it might still be possible to run into a situation where the builder simply doesn't know what to do. As long as you're filling in the individual properties, I think you should be fine. I'm hoping to address get-only collection properties soon so that the builder will have the ability to clear an existing collection rather than completely replacing it.

[MelGrubb]

I've been away from my own project development for a while, but now that I've taken a second look at this, I don't think there is a bug here. If your class were initializing the EmailRecipients property, then I think the default behavior of the builder would still replace that property with the default value of ICollection, which would be null. All you need to do to get around this though is to add a call to WithEmailRecipients and pass in a value that implements ICollection just like any other property.