locked
Custom attributes not propagated (for AllowMultiple=true custom attribute) RRS feed

  • Question

  • Hi there,

    I have a custom attribute:

    [AttributeUsage(AttributeTargets.Field | AttributeTargets.Property, AllowMultiple=true)]
    public class MyDisplayAttribute : Attribute
    {
        int Order {get;set;}
        string PropertyName {get;set;}
    }
        [MetadataTypeAttribute(typeof(Individual.IndividualMetadata))]
        public partial class Individual
        {
            internal sealed class IndividualMetadata
            {
    
                // Metadata classes are not meant to be instantiated.
                private IndividualMetadata()
                {
                }
    
                [Include]
                [MyDisplay(Order = 3, PropertyPath="LastName")]
                [MyDisplay(Order = 2, PropertyPath="FirstName")]            
                public Contact Contact;
    

    The second [MyDisplay] attirbute is not propagated to the generated file (however the first instance is proving that there is nothing wrong with the attribute itself). The RIAServicesOverviewPreview.pdf document does not indicate that Multiple properties would NOT be propagated so I am wondering if this an omission in the documentation (i.e. intended behaviour) or a bug.

     Thank you,

    Narayan

     
     

     

    Sunday, August 23, 2009 7:17 PM

Answers

  • I believe you are hitting a subtle bug in Attribute.TypeId that fools the TypeDescriptionProvider layer we use for metadata.

    Try overriding the virtual Attribute.TypeId on your attribute and ensure you return a unique value.   The lowest level Reflection-based TDP maintains a hash to avoid acquiring duplicates, but a bug in the Attribute.TypeId implementation returns a TypeId that is the same for all attributes of the same type.  This means your 2nd and 3rd, and 4th instances of this attribute are considered duplicates of the first, no matter what they contain.

    This bug has bitten us too.  The basic rule here is that any AllowMultiple=true attributes must override TypeId to make it through the TDP layers.

    We've communicated this problem to the owners of Attribute and TDP, but the "fix" would constitute a breaking change and cannot be done.

    See http://msdn.microsoft.com/en-us/library/system.attribute.typeid.aspx .

    Ron Cain [MSFT]

    Friday, August 28, 2009 8:45 AM

All replies

  • It's probably due to the fact that the "MyDisplayAttribute" class isn't defined/recognized in the Silverlight client. Have you tried adding the class to the Silverlight-project to see it that makes any difference?

    Monday, August 24, 2009 2:48 AM
  • Hi Theo,

    Thanks for the post however, that's not the issue. The first "MyDisplayAttribute" does get propagated to the client however, the second instance doesn't. This means the class is definately defined/recognized in the Silverlight client.

     Narayan

    Wednesday, August 26, 2009 7:52 PM
  • I believe you are hitting a subtle bug in Attribute.TypeId that fools the TypeDescriptionProvider layer we use for metadata.

    Try overriding the virtual Attribute.TypeId on your attribute and ensure you return a unique value.   The lowest level Reflection-based TDP maintains a hash to avoid acquiring duplicates, but a bug in the Attribute.TypeId implementation returns a TypeId that is the same for all attributes of the same type.  This means your 2nd and 3rd, and 4th instances of this attribute are considered duplicates of the first, no matter what they contain.

    This bug has bitten us too.  The basic rule here is that any AllowMultiple=true attributes must override TypeId to make it through the TDP layers.

    We've communicated this problem to the owners of Attribute and TDP, but the "fix" would constitute a breaking change and cannot be done.

    See http://msdn.microsoft.com/en-us/library/system.attribute.typeid.aspx .

    Ron Cain [MSFT]

    Friday, August 28, 2009 8:45 AM
  • Thanks Ron. I guess we should be thankful of bugs with relatively simple workarounds :)

    Narayan

    Saturday, August 29, 2009 10:31 PM