shouldn't we add a csproj entry to pack as a tool instead and then it would just work?

The reason that I've decided to build the package "manually" here is that we then don't require the preview SDK on AppVeyor. The dotnet cli tooling for building tool packages is a little rough around the edges in its current state. The package we produce is exactly the same as you would get from the dotnet pack command. We can always change this later when the tooling matures and 2.1 is RTM

@filipw Bottom line here is that I really don't want to mess with preview SDK's up on AppVeyor. We change this to dotnet pack when the RTM ships. Another thing I took into consideration is that we currently publish the following packages to NuGet.

• Dotnet.Script.0.19.0.nupkg
• Dotnet.Script.Core.0.19.0.nupkg
• Dotnet.Script.DependencyModel.0.5.0.nupkg
• Dotnet.Script.DependencyModel.NuGet.0.5.0.nupkg

These are all "library" packages and packaging Dotnet.Script.0.19.0.nupkg as a tool would change the meaning/content of the package.

Therefore I went with packaging the tool as dotnet-script.0.19.0.nupkg where the package name matches the tool name. You install a tool named dotnet-script and that is exactly what you get 👍

The thing is, Dotnet.Script.0.19.0.nupkg is also a tool 😄In fact that package was meant to be used as tool only, except the old SDK only allowed local tools (and global ones using the PATH trickery and so on).
So there is no point in having 2 separate packages, both behaving as "tools", one according to new SDK, one according to old SDK. I'd rather just break the existing one.

I now realized we lost it from the Readme at some point, but the reason why Dotnet.Script package exists is so that you can use <DotNetCliToolReference> and install it into your current folder without installing globally. This should still work with 2.1 though.

Got it. Having two packages does not make sense. 👍

As I see it we have two possibilities here

1. Unlist Dotnet.Script.0.19.0.nupkg and introduce dotnet-script.0.19.0.nupkg

Personally I like dotnet-script better than Dotnet.Script for this package since the package name resembles the tool name and the package name also matches the "product name"
It also sets the package apart from the other NuGet packages which are library packages.

dotnet install tool -g dotnet-script

vs

dotnet install tool -g Dotnet.Script

2. Publish the global tool as Dotnet.Script

Don't mean to be picky, just making sure all the cards are on the table before we decide 😄

I now realized we lost it from the Readme at some point, but the reason why Dotnet.Script package exists is so that you can use and install it into your current folder without installing globally. This should still work with 2.1 though.

@filipw Did a quick test here and it does not seem like you can use a global tool as a <DotNetCliToolReference> .

This works though (using the DotNet.Script library package currently on NuGet)

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp2.0</TargetFramework>
  </PropertyGroup>
  <ItemGroup>
    <DotNetCliToolReference Include="Dotnet.Script" Version="0.19.0" />
  </ItemGroup>
</Project>

This does not work (using my local global tool package)

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp2.0</TargetFramework>
  </PropertyGroup>
  <ItemGroup>
    <DotNetCliToolReference Include="dotnet-script" Version="0.19.0" />
  </ItemGroup>
</Project>

HOWEVER, the https://www.nuget.org/packages/dotnet-serve/ works as a global tool AND a local DotNetCliToolReference I need to look more into this. If we can make Dotnet.Script work as a local tool AND a global tool, I agree that we continue with Dotnet.Script as the package name.

@filipw Our global package targets netcoreapp2.0 and I can't seem to get that installed as a local package. What if we publish Dotnet.Script.0.20.0.nupkg as a tool so that we at least can install it a a global tool. Then when 2.1 hits RTM we should be able to make the same package work work local tools as well. This means no new package name, just turning Dotnet.Script.0.20.0.nupkg into a tool package.

there is a typo here

I'll fix