Skip to content

Add AssemblyTargetFramework to IExtensionNode - #1867

Open
HarnageaGabriel wants to merge 1 commit into
mainfrom
fix/issue-1866-extension-node-target-framework
Open

Add AssemblyTargetFramework to IExtensionNode#1867
HarnageaGabriel wants to merge 1 commit into
mainfrom
fix/issue-1866-extension-node-target-framework

Conversation

@HarnageaGabriel

Copy link
Copy Markdown
Collaborator

Summary

  • Adds AssemblyTargetFramework (System.Runtime.Versioning.FrameworkName) to IExtensionNode, alongside the existing AssemblyPath/AssemblyVersion, populated the same way from ExtensionAssembly.FrameworkName in ExtensionNode's constructor.
  • Simplifies the workaround added by Fix --list-extensions showing wrong target framework for extensions #1861 (fixing Error with --list-extensions listing for extension that target .NET Standard #839): ConsoleRunner.DisplayExtension previously had to independently re-read each extension assembly's metadata via Mono.Cecil/TestCentric.Metadata (GetTargetFrameworkDisplayName) just to display its target framework, since the interface didn't expose it. That method is now removed and the console reads node.AssemblyTargetFramework directly. The now-unused TestCentric.Metadata package reference is dropped from nunit4-console.csproj (still used elsewhere in the solution, so the central PackageVersion entry is untouched).

Fixes #1866

Test plan

  • dotnet cake -t Test (via build.cmd -t Test) — full Build + Test succeeded (300/300 net462 non-skipped tests passed, 313/313 net8.0 non-skipped tests passed).
  • build.cmd -t Package fails locally with MSB4041 on nunit.extensibility.api.csproj, but this reproduces identically on a clean checkout of main with no changes applied — pre-existing local MSBuild-toolchain issue (old .NET Framework MSBuild 4.8 invoked by the Package task can't parse the SDK-style <Project Sdk=...> project), unrelated to this change.

…r workaround

IExtensionNode already exposed AssemblyPath and AssemblyVersion; add
AssemblyTargetFramework (System.Runtime.Versioning.FrameworkName),
populated the same way as AssemblyVersion from
ExtensionAssembly.FrameworkName.

PR #1861 (issue #839) worked around the missing property by having
ConsoleRunner independently re-read the extension assembly's metadata
via Mono.Cecil/TestCentric.Metadata just to determine its target
framework. Now that the engine's own extension node exposes this
directly, replace that workaround with a direct read of
node.AssemblyTargetFramework and drop the now-unused
TestCentric.Metadata dependency from the console project.

Fixes #1866

@CharliePoole CharliePoole left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to merge. Thanks!

@CharliePoole

Copy link
Copy Markdown
Member

@HarnageaGabriel You didn't request a review but I guessed you were done and reviewed it. You can merge or continue working if you wanted to add anything. In that case just re-request a review when you're done.

In future, unless you prefer a particular person, you can just request a review from the engine core team and we'll all get notified.

@CharliePoole

Copy link
Copy Markdown
Member

@HarnageaGabriel Ping!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Add TargetFramework of the extension assembly to IExtensionNode

2 participants