Multi-targeted Engine Extensions

It would be good to support multi-targeted engine addin’s. Two motivations:

1. To allow extensions to target two different .NET Framework versions, where there is a significant advantage to build a version targeting a higher framework, but we don’t wish to drop support for older frameworks. https://github.com/nunit/vs-project-loader/issues/25 is a great example of this.

2. To allow the packaging of extensions for potential separate .NET Standard and .NET Framework engines, which we may have in the future.

Here’s a rough breakdown of what I think would be involved:

• Allow engine to prioritise ‘highest possible’ available framework of addin.
• Permit engine to safely ignore extensions targeting a framework which can’t be loaded. (May already exist?)
• Define .addins file format for these situations, closely tied to the recommended NuGet packaging method of extensions.

Here’s some of my thoughts on how to go about this - comments welcome:

Updated post-discussion 02/04/18

Extension precedence The engine already has code to select the extension of the highest assembly version, when multiple extensions of the same type are available. I propose we expand this to look at Highest Assembly Version and then ‘Best’ target framework.

For the sake of consistency with the wider .NET ecosystem, I think our definition of ‘Best’ framework should match NuGet’s. We can limit the overhead by only initially implementing support for addins targetting .NET Framework or .NET Standard.

NuGet packaging of Extensions ~For consistency with the wider .NET ecosystem, I believe we should aim to make use of the existing multi-target packaging conventions introduced by NuGet - or the defaults created by dotnet pack on a multi-targeting project.~

~We currently seem to package our extensions under /tools/ in their NuGet package. Is this the right location, given the main engine NuGet package, packages that under /lib/? The NuGet docs recommend /tools/ for “Powershell scripts and programs accessible from the Package Manager Console”.~

~Taking account of backwards compatibility - I’d like to look at repackaging our extension dll’s with the dlls under the /lib/ directory - as I believe is more standard. I could be wrong there - open to discussion on this one with people more knowledgable than me!~

We’ll continue to package extensions under the tools subdir. We’ll add in framework specific subdirectories, as below:

tools -> net20 -> extension.dll
      -> net45 -> extension.dll

Addins file format/NuGet packaging The format of the addins file itself doesn’t need to change - it can of course be pointed at a specific dll targeting a specific platform already. The question to look at here is the paths we put in the default .addins files to cater for NuGet and .msi installations.

I’d be tempted just to add an extra level of wildcard directory to the existing paths for msi/NuGet resolution, and have the engine attempt to load all extensions following the extension precedence logic described above. This is less efficient than attempting to read directory names and work out the , but would simplify the code, as the below functionality would already be required, given the current functionality to specify specific paths in the .addins file. Thoughts on this bit?

To ensure backwards compatibility between new extension packages, and old engine installations, and .addins file will be added to the tools directory of new extensions with subdirectory. This will allow the .addins files to ‘chain’ - and old engines to locate new addins, without the user needing to make any manual edits to the addins file.

This is spun out of https://github.com/nunit/nunit-console/issues/388. @rprouse - if you had particular plans for this part, feel free to boot me off and take the issue back! 😄

[jnm2]

it may be useful as an override, but imo we shouldn’t add that override until we have a usecase for it!

This makes sense! Thanks, both of you!

[CharliePoole]

@ChrisMaddock Of course, that has to be “highest target framework loadable under the current runtime.”

WRT “special comment” it’s an example of how you could add special handling per runtime without constraining the names of the directories. I agree we shouldn’t add it unless there’s a demonstrated need.