Static UniqueForTargetFramework(Assembly) overloads ignore the assembly passed to them #1851

VerifierSettings.UniqueForTargetFramework(Assembly) and VerifierSettings.UniqueForTargetFrameworkAndVersion(Assembly) had no effect: the assembly argument was stored but never read.

Both statics record the framework name on the shared namer:

public static void UniqueForTargetFramework(Assembly assembly)
{
    InnerVerifier.ThrowIfVerifyHasBeenRun();
    SharedNamer.UniqueForTargetFramework = true;
    SharedNamer.SetUniqueForAssemblyFrameworkName(assembly);
}

but the only consumer, PrefixUnique.AppendTargetFramework, read the instance namer's field directly rather than calling the resolver that falls back to SharedNamer:

var name = namer.UniqueForTargetFrameworkName;

Namer.ResolveUniqueForTargetFrameworkName() existed for exactly this and had zero call sites. The sibling AppendAssemblyConfiguration does use its resolver, which is what makes the omission visible.

Symptom

A module initializer calling VerifierSettings.UniqueForTargetFramework(typeof(LibUnderTest).Assembly), where that assembly targets a different framework from the test assembly, silently gets the test assembly's TFM in the file name instead of the one explicitly passed.

Where the test assembly carries no TargetFrameworkAttribute, it is worse than silent: the static Namer.TargetFrameworkName fallback throws

UniqueForTargetFrameworkAndVersion or UniqueForTargetFramework used but no `TargetFrameworkAttribute` found.

even though the caller supplied an assembly that has one.

Fix

Read through the resolver, matching how assembly configuration already resolves.

Fixed in 090d648, covered by UniqueForAssemblyTargetFrameworkTests.