Ship Wyam as a .NET Core Global Tool

[tonerdo]

Once #300 is done then I think it'll be very useful to have Wyam distribute as a .NET Core Global Tool (dotnet/cli#5147). So users can just do:

dotnet tool install -g Wyam

and be well on their way with the wyam command added to PATH

[daveaglick]

Totally agree. My current thinking on clients for Wyam 2.x is that we’ll ship:

• .NET Framework .zip archive
• .NET Core .zip archive
• Chocolatey package (.NET Framework)
• .NET Core global tool
• .NET Framework tools package
• .NET Core tools package

Those last two tools packages may be able to consolidate into one - I’m not clear on how/if tools packages targeting multiple runtimes work.

[MisinformedDNA]

What do you gain from supporting .NET Framework? I'm new to Wyam, but it's just a tool right? So no one would need to be using .NET Framework. Seems like unnecessary complexity.

[daveaglick]

@MisinformedDNA That's an excellent question. My assumption is that there are probably folks who for one reason or another can't or don't want to install .NET Core. The reach of .NET Framework is still pretty high and making sure we produce an executable for those folks gets the tool into the most hands.

The cost of producing a .NET Framework build shouldn't be very high. Since all the supporting libraries target .NET Standard (or will soon if they don't already), producing the zip file and tools package for Core and Framework mostly becomes a matter of getting the multi-targeting right.

[LokiMidgard]

Could .Net Framework module library's used in an .net core only wyam?

If not, that could be a reason. There have been modules that were removed because they can't support .net core. I'll still use those and haven't updated wyam since then. But I've always planed to extract them from the history and host them as independent packages. And the day will come when I update to the current version.

[daveaglick]

I'm going to close this issue out in favor of #668 where the client roadmap for 2.x is discussed in more detail