Command Line Tools Missing in 4.0.1 Nuget Package

[groogiam]

The Nuget Package for version 4.0.1 seems to be missing the command line tools.

[dradovic]

It was a conscious choice when switching to v4.x (supporting .NET Core) to omit the command line tools. At the time, I asked on SO the following question: Best practice to include console app in NuGet. Reading the answers, it seems that NuGets are not meant to include command line apps.

At this stage, I made the decision to omit the previously shipped command line tool to get a feedback from the community.

How would you tackle this?

[dradovic]

I also want to mention that I personally never used that command line tool. Mig#'s API is really simple to use from any kind of app directly so why should I deliver a console app with a predefined way of configuring connection strings for example. Jumping to .NET Core opens a whole array of possibilities of how somebody would want to configure Mig# or design a console app.

So I'm thinking of leaving it open to the user of how to use the class API instead of providing "standard" console apps for different platforms.

If you're still on .NET Framework and you're used to the console app it has been, you can still compile it using the sources yourself. At least that's one possibility.

[groogiam]

The command line tools provide easy ways to generate scripts and apply migrations especially when it comes to the dev workflow and from a continuous integration standpoint. I understand the fact that you can use the api to implement your own migration processes, but by only excluding a simple command line runner you are essentially forcing everyone who uses your tool to reinvent the wheel. The command line tools provide a quick way to get started using the tool and cover the 80-90% use case.

As far as .NET Core goes you could mutli target the command line tools to run in either Framework or NetCoreApp.

[dradovic]

I get and share your point about reinventing the wheel.

I wouldn't want to multi-target the same console app. A .NET Core app should use the .NET Core configuration capabilities to get the connection strings. Also, probably it should be a CLI tool as mentioned in this answer. However as it stands, I currently do not have any incentive to provide that.

What I could imagine is to continue to provide the command line tool for .NET Framework as it used to be. However, it raises the question of how to package that because the tools folder seems to be the wrong place for that.

[groogiam]

I was simply suggesting multi targeting the current command line tools for both .NET Core and .NET Framework and then including them in the nuget package. If I'm not mistaken this can be accomplished with some changes to the respective project files. I don't see whats wrong with putting the binariesin the nuget package tools folder?

[dradovic]

Please study the SO question referenced earlier in order to understand what might be wrong with packaging the command line tool in the same NuGet.

Also, I have switched to developing under .NET Core on Linux - I currently don't even have a box with .NET Framework on it.

Thus, I'm coming to the following conclusion. In order to not having to reinvent the wheel, it would be indeed nice to have a NuGet containing the command line tool as it was. However, that tool won't be part of the main distribution (i.e. the MigSharp NuGet) anymore starting with 4.x. It needs to be a separate NuGet or whatever package manager the community chooses. It could even be that in the future there will be a MigSharp.Migrate NuGet and a MigSharp.Cli NuGet that does things the new way (e.g. also dropping the need for command line args parsing). This approach will also show some download stats indicating the appetite for it.

Since I'm not using the command line tool nor .NET Framework I won't be the guy providing that extra NuGet (for now). Whoever wants and needs it is welcome to compile the command line tool and package it under a NuGet of its own so that the community can benefit from it.