sdk: Global tools targeting netcoreapp2.0 do not work with preview2 SDK

I would like to +1 this - this issue has broken https://github.com/filipw/dotnet-script/ as well, which is targeting netcoreapp2.0 as well.

With preview1, it was generating dotnet-script.exe.config in the .dotnet/tools folder upon installation. Now with preview2, a dotnet-script.startupconfig.json is being generated.

It seems that the problem is with that appRoot path found in that startup JSON file, as it is not being respected by the generated shim EXE. Instead of using the path to find dependency DLLs, it searches for them in the current folder, hence the error mentioning a DLL under the current path:

Unhandled Exception: System.IO.FileNotFoundException: Could not load file or assembly 'C:\Users\xxx\.dotnet\tools\dotnet-script.dll'. The system cannot find the file specified.

If I copy the generated dotnet-script.exe into the tool package folder (so C:\Users\xxx\.dotnet\tools\.store\dotnet-script\0.21.0\dotnet-script\0.21.0\tools\netcoreapp2.0\any, then the shim works.

If possible, it would be great if this could be fixed rather than simply communicated as a breaking change.

So, dependencies should not be a problem.

In the case of dotnet-script project, it is a C# script runner, and it compiles your scripts by combining your own script-level references and some implicit references inherited from the runner itself. Long story short, if the script wants to be executed as netcoreapp2.0 it cannot be fed the implicit inherited dependencies from the host runner which is built against netcoreapp2.1.

I am sure I do not see the full picture here, but it sounds like you could have made it work with netcoreapp2.0 (after all, it worked already) but it was consciously decided to take advantage of a the runtime feature of netcoreapp2.1? Is this driven by an expectation that people would not use netcoreapp2.0 once netcoreapp2.1 comes out? Also, aren’t the global tools part of SDK, which should be kind of independent of the runtime? 🙂

Is there any workaround for that? Could I for example bring my own shim instead of rely on the generated one?

if you target netcoreapp2.1 and recompile, it works. but if you target netcoreapp2.0 and recompile (using the new SDK), it doesn’t work.

Not every tool can afford to retarget itself into netcoreapp2.1 straight away, as there could be other considerations and dependencies. I think it would be a shame if global tools were only allowed if one targets netcoreapp2.1, which seems to be the case now.

@KathleenDollard if you target netcoreapp2.1 and recompile, it works.

I played with netcoreapp2.0, and it seems this is completely busted. I’m re-opening as it seems like either:

• the SDK should fail when TargetFramework != netcoreapp2.1 and PackAsTool == true
• fix global tools so they work for all versions of netcoreapp.

Repro:

dotnet new console -o testclitool
cd testclitool
dotnet pack -o pkgs -p:PackAsTool=true -p:TargetFramework=netcoreapp2.0
dotnet tool install --tool-path $(pwd)/.tools --source-feed $(pwd)/pkgs testclitool

Error

Failed to locate managed application [/private/tmp/testclitool/.tools/testclitool.dll]

So, are you saying that global tools don’t work for console apps that target netcoreapp2.0?
If so, that seems like either a bug or a serious design flaw.

FYI the templates should produce a project that effectively looks like this.

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <PackAsTool>true</PackAsTool>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp2.0</TargetFramework>
  </PropertyGroup>
</Project>