I have this Field mapped onto related field

        /// <summary>Gets the value of the related field this.StaffMemberToBeTrackedBy.StaffMemberName.<br/><br/></summary>
        [Display(ResourceType = typeof(Labels), Name = "Form_StaffMemberName")]
        [Required(ErrorMessageResourceType = typeof(AdminStrings), ErrorMessageResourceName = "RequiredStaffName")]
        public virtual System.String StaffMemberToBeTrackedByName
        {
            get { return this.StaffMemberToBeTrackedBy==null ? (System.String)TypeDefaultValue.GetDefaultValue(typeof(System.String)) : this.StaffMemberToBeTrackedBy.StaffMemberName; }
        }

but the designer/generator copies all the attributes from the related field (StaffMemberEntity.StaffMemberName) and ignores any I have put on the StaffMemberToBeTrackedByName property.

In this case (and I imagine in most cases) this is not desirable. Is there anyway to prevent this?

Version 5.5 and earlier

Looks like a bug in the code generator (TDL interpreter), where it ignores the 'RelatedField' argument of the Foreach Attribute loop.

I can reproduce it indeed: ignores the Field mapped onto related field (forf)'s attribute and emits the attribute of the related field. This isn't how it should work, as forf's have their own attribute definitions/rules.

Looking into it.

It's present since the beginning of this feature, in 2009. I can imagine people using the 'broken' behavior, namely they get the attributes like 'DataMember' defined on the related field now automatically defined on the Forfs. 'Fixing' this, will break that code and will require them to define the attribute also at the Forf level. Which might be a small task, but it's still a breaking change. We normally won't do that on a bugfix release (which these are, 5.4.4 & 5.5.1).

It sucks, as it's potentially a 1 line change (Line 5023 in Interpreter.cs, change:

case Token.RelatedEntityField:
    settingValuesTarget = _currentRelatedEntityField;    // Line 5023
    break;

Into

case Token.RelatedEntityField:
    settingValuesTarget = _currentFieldOnRelatedField;
    break;

and it will work properly, but have to check whether it will work in other loops using the same method)

and there's no easy workaround either.

I'm very reluctant to make this change at this point, as it's a breaking change and I really want to schedule this for 5.6. I know that sucks, but it's something we normally won't do as potentially breaking other people's code is something we try to avoid during bugfix releases (5.5.x)

That said, the feature has never worked as intended: defining an attribute on the field mapped on related field was never honored, as the method to obtain the object containing the attribute definitions always returned the object of the related field instead. So in all cases the user using this feature today got the attribute of the related field.

We've to think about it, but for now assume this won't be fixed before 5.6

That's OK I wasn't holding out much hope for a quick resolution. I've reverted the code back to using

interface IStaffMemberMetadata
{
            [Required(ErrorMessageResourceType = typeof(AdminStrings), ErrorMessageResourceName = "RequiredStaffName")]
            object StaffMemberName { get; set; }
}

[MetadataType(typeof(IStaffMemberMetadata))]
public partial class StaffMemberEntity

I was in the process of doing away with MetadataType etc but I guess this is the reason I used it back in the day.

Be good to see it sorted in the next version.

Thanks for understanding. Yes, we'll fix it in 5.6

Fixed for v5.6