Avoid hardcoded TFM in illink

[ViktorHofer]

runtime/src/tools/illink/src/ILLink.Tasks/LinkTask.cs

Line 272 in e476b43

_illinkPath = Path.Combine (Path.GetDirectoryName (taskDirectory), "net9.0", "illink.dll");

There are ways to avoid this hardcode, i.e. by passing in an additional parameter to the msbuild task or by inferring it somehow else. I would assume that the linker.dll and the ILLink.Tasks.dll TFM should be in sync and could be read from the assembly metadata.

@sbomer @agocke

[am11]

I would assume that the linker.dll and the ILLink.Tasks.dll TFM should be in sync and could be read from the assembly metadata.

Perhaps with this approach:

runtime/src/coreclr/tools/r2rtest/Commands/CompileNugetCommand.cs

Lines 61 to 62 in e476b43

	Version version = Environment.Version;
	string targetFramework = $"net{version.Major}.{version.Minor}";

(it's sourcegen'd these days 426edd0 🙂)

[ViktorHofer]

Doesn't this create a dependency between the System.Private.CoreLib version and the linker TFM? Those aren't necessarily in sync, i.e. right now they aren't.

[am11]

During this transition period, VMR is looking for net10.0, while the hardcoded version is net9.0. Do you mean if we use Environment.Version then VMR will succeed but the regular runtime build will fail (until the transition is completed)? In which case, your approach it is; get current assembly (of ILLink class) and read the version from metadata.

[ViktorHofer]

Do you mean if we use Environment.Version then VMR will succeed but the regular runtime build will fail (until the transition is completed)?

Correct. If we would switch to Environment.Version now, the runtime PR with that change would fail. I would prefer to avoid coupling the version of SPC with the linker.dll TFM.

[am11]

I tried three variants: Environment.Version, typeof(ILLink)..InformationalVersion and executingAssembly..InformationalVersion, none of them worked because in current state of runtime, all live assemblies have 10.0 version, yet illink.dll lands in net9.0:

% find artifacts/bin -name illink.dll
artifacts/bin/ILLink.Tasks/Debug/net9.0/illink.dll
artifacts/bin/Mono.Linker/ref/Debug/net9.0/illink.dll
artifacts/bin/Mono.Linker/Debug/net9.0/illink.dll

[am11]

If it is guaranteed to either have the same version or N-1, one simple approach is to probe paths (in more likely to less likely order) main...am11:runtime:patch-17.

[ViktorHofer]

If we want to / can rely on reflection then we could probably directly read from the TargetFrameworkAttribute assembly attribute:

typeof(ILLink).Assembly.GetCustomAttribute<TargetFrameworkAttribute>

Apparently we still need to parse that string but it's the right input to look at:

[am11]

typeof(ILLink).Assembly.GetCustomAttribute<TargetFrameworkAttribute>

I think this will fail in netfx case:

runtime/src/tools/illink/src/ILLink.Tasks/ILLink.Tasks.csproj

Line 4 in d0ee906

<TargetFrameworks>$(NetCoreAppToolCurrent);$(NetFrameworkToolCurrent)</TargetFrameworks>

[ViktorHofer]

Oh I wasn't aware that the .NET Framework task invokes the .NETCoreApp illink.dll. Interesting.