Scott Hernandez wrote:
>
>>
>
>What about following the xml serialization standard and call them
>XmlAttributeAttribute and XmlElementAttribute? We could even set them as
>derived classes of the serialization ones.
>
I thought about this. Do we get any benefit from deriving from the
serializatio
[snip]
> >Then we would change Element.InitializeAttributes to get all members
> >that have a TaskElementAttribute and their return type. If the return
> >type derives from Element, follow the same rules we do for
> >BuildElementAttribute matches.
> >
> How is this different to what happens now
Scott Hernandez wrote:
>I would agree that they do not need to be unique. But task names do,
>right?
>
yep
>
>BTW. Maybe we should use a scheme like I described below to guarantee we
>don't have dupl. task names defined. Right now, the first named task
>that matches is always returned.
>
Thats t
I would agree that they do not need to be unique. But task names do,
right?
BTW. Maybe we should use a scheme like I described below to guarantee we
don't have dupl. task names defined. Right now, the first named task
that matches is always returned.
It seems like we are trying to use TaskAttrib
Scott Hernandez wrote:
>Looking through the code I found that both NUnit.FormatterElement and
>TStampTask define an element named "formatter". I know this is fine now,
>since you looking at TaskNameAttributes, but should this be fixed?
>
I'm not sure these element names need to be unique. The tS
Looking through the code I found that both NUnit.FormatterElement and
TStampTask define an element named "formatter". I know this is fine now,
since you looking at TaskNameAttributes, but should this be fixed?
If these are to be unique, it might make sense to keep a static class
that can be used
