Sdk: Is prefercliruntime the preferred solution for CLI tools?

[alfonsogarciacaro]

Related: https://github.com/fable-compiler/Fable/issues/961#event-1099667439

Hi there! Recently a user has reported a problem with dotnet-fable CLI tool as apparently the tool won't run if the user has a lower dotnet SDK (and thus coreclr runtime) patch version than the one used to build it. This behavior doesn't look very intuitive as netcoreapp target frameworks don't include a patch version (netcoreapp1.0, netcoreapp1.1), and one would expect the tool to work with all coreclr 1.0.x runtimes, or at least to be able to set the minimum patch version explicitly instead of letting MSBuild do it for you.

However, @enricosada has explained to me the tradeoffs for CLI tools and suggested to use a prefercliruntime file to avoid the error. The question then is: is this the preferred solution for all CLI tools? If so, could it be documented somewhere, added to CLI tools templates, improve the error message users see when it's missing, etc?

Thanks a lot for your help!

[livarcocc]

That should work for you. The prefer CLI runtime will roll the tool forward to whatever runtime the CLI is using, without crossing major versions, as that is not supported.

So, with the prefer CLI runtime, we will run your tool in 1.X but will not run it in 2.X. Makes sense?

[alfonsogarciacaro]

Thanks a lot for the clarification, @livarcocc! As commented above, coming from the .NET Framework world I would assume I can target a minimum version so the app can run on that version and above. But I understand netcore 2.0 is not backwards compatible (as it was the case with .NET Framework 2.0) and I can update my app when necore 2.0 RTM is out, so at least in my case that's not a problem.

However, my question was more about whether the prefercliruntime file should the preferred/recommended/default way for CLI tools, or is there any other solution to solve conflicts with the runtime version installed in final users' machines?

[alfonsogarciacaro]

Talked to @dsplaisted today about this. He recommended to set explicitly the minimum target framework patch version and rely on prefercliruntime only to allow runtimes with higher minor or patch versions. I think that makes sense so we can close this issue, but I would like to make a couple of questions to clarify.

• Does prefercliruntime only roll the tool forward then? In the issue linked on top, the tool targeted netcore runtime 1.0.5 but the user had 1.0.4 and 1.1.0. After adding the prefercliruntime file is the tool being run with runtime 1.1.0? I thought CLI tools couldn't target necoreapp1.1.
• @dsplaisted told me the name of the MSBuild property to set the runtime version but I forgot it and couldn't find it in the documentation. Which one is it and how is it used?

[enricosada]

runtime 1.1.0? I thought CLI tools couldn't target necoreapp1.1

i think when running it on os with just 1.1, will just pass --fx-version 1.1 argument of dotnet exec to override what runtime use.

@dsplaisted told me the name of the MSBuild property to set the runtime version but I forgot it and couldn't find it in the documentation. Which one is it and how is it used?

@alfonsogarciacaro grepping dotnet msbuild /pp > logpp.txt

  <ItemGroup Condition=" '$(DisableImplicitFrameworkReferences)' != 'true' and '$(TargetFrameworkIdentifier)' == '.NETStandard'" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
    <PackageReference Include="NETStandard.Library" Version="$(NetStandardImplicitPackageVersion)" IsImplicitlyDefined="true" />
  </ItemGroup>
  <ItemGroup Condition=" '$(DisableImplicitFrameworkReferences)' != 'true' and '$(TargetFrameworkIdentifier)' == '.NETCoreApp'" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
    <PackageReference Include="Microsoft.NETCore.App" Version="$(RuntimeFrameworkVersion)" IsImplicitlyDefined="true" />
  </ItemGroup>

so $(RuntimeFrameworkVersion) for Microsoft.NETCore.App, and $(NetStandardImplicitPackageVersion) for netstandard.library packages

[livarcocc]

Closing this issue since the questions here seem to have been clarified a while ago.