Validate manually-configured ErrorMessageResourceType+Name against the specified resource type

[Copilot]

When a user explicitly sets both ErrorMessageResourceType and ErrorMessageResourceName on a validation attribute, the weaver silently skipped all validation — meaning a missing resource key would not be caught at build time. Any validation that did occur would have checked against the global resource type rather than the specified one.

Changes

• ModuleWeaver.cs: ScanMember now also collects attributes that have both ErrorMessageResourceType (non-null) and ErrorMessageResourceName explicitly set. ProcessClasses validates these manually-configured pairs against their specified type (grouped by TypeReference.FullName) rather than the global type. Attributes with ErrorMessage set are still skipped.

• WeaverExecutor.cs: Added optional additionalEmbeddedResourceFiles parameter (IReadOnlyDictionary<string, IEnumerable<KeyValuePair<string, string?>>>) to support embedding multiple resource files in test assemblies.

• AutoLocalizeValidationAttributesAttributeTests.cs: Two new tests covering the scenario with a non-global OtherStrings resource type:

  • Resource name exists in specified type → no error
  • Resource name missing from specified type → error referencing UnitTest.OtherStrings, not UnitTest.AppStrings

// Previously: silently skipped, missing key only caught at runtime
// Now: weaver validates "OtherStrings_Required" exists in UnitTest.OtherStrings.resources
[Required(
    ErrorMessageResourceType = typeof(UnitTest.OtherStrings),
    ErrorMessageResourceName = "OtherStrings_Required")]
public string Name { get; set; }

---

📱 Kick off Copilot coding agent tasks wherever you are with GitHub Mobile, available on iOS and Android.