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

Steps to reproduce

• Create dotnet global tool dotnet new global-tool -n my-tool --command-name go
• dotnet pack --ouput ./
• install dotnet tool install -g my-tool --source ./
• run go

Error in latest SDK (see --version below) A fatal error was encountered. The library ‘hostpolicy.dll’ required to execute the application was not found in ‘C:\Program Files\dotnet’.

same on macOS A fatal error was encountered. The library ‘libhostpolicy.dylib’ required to execute the application was not found in ‘/usr/local/share/dotnet’.

Environment data

dotnet --info output:

.NET Core SDK (reflecting any global.json):
 Version:   2.1.300-preview2-008530
 Commit:    822ae6d43a

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.17133
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\2.1.300-preview2-008530\

Host (useful for support):
  Version: 2.1.0-preview2-26406-04
  Commit:  6833f3026b

[filipw]

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.

[filipw]

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?