When using tags with the in-process runner

[michael-bird]

When using the in-process runner, is the only way to set the tags used for migrations to use ConfigureServices with the method below?

.Configure<RunnerOptions>(opt => { opt.Tags = new[] { "Demo" }; }))

Or is there another way to set tags?

[jzabroski]

@michael-bird What problem are you trying to solve?

I do want to make the in-process runner more modular and have some ideas but lack the time to implement it. If you'd be interested in taking it up I can provide my general thoughts. #1208 covers the general idea that ideally it would be much easier to create an in-process runner with all the core features of FluentMigrator.DotNet.Cli package, but with the added benefit of opting in to MSBuild's ResolvePackageAssets task to generate a proper, application-specific project.assets.json for the executable.

[michael-bird]

I have a console application that I am using in a Github action and I wanted to pass the tags as args to the console app so it works like the cli when you run the migrations. Maybe this isn't the best idea.

[jzabroski]

That is exactly the point of #1208 - effectively creating an abstract base class others can extend. I think your idea is fine, but the implementation details probably matter, too. One thing that is not great about the McMaster Command Line library is that it is not easy to use the commands as a library because it uses attribute annotations. The attribute annotations make it fairly easy to find related commands and traverse the code within an IDE like Visual Studio, but it does not lend itself well to whole cloth composition. In this one regard, Microsoft's System.CommandLine is actually a better library, because you can re-package Options as you wish through model binding: https://learn.microsoft.com/en-us/dotnet/standard/commandline/model-binding

[michael-bird]

Cool, I am using a framework called Cocona for the console app. I will take a look at the issue and see if I can think of anything. Thanks for your help.

[jzabroski]

I think that is probably where your approach may struggle. I don't know the full scope of Cocona, but the README.md does not demonstrate ability to handle robust command line options or explain its token parsing model (some command line parsers have ambiguous parse forests in their API, like FluentCommandLineParser, and should absolutely be avoided by any responsible engineer who understandings the topic of parsing well enough to realize the bugginess this could cause).

When FluentMigrator.DotNet.Cli was first written, System.CommandLine did not exist. You could imagine a Builder pattern that allows picking and choosing which options to plug-in to a root command, so that you can pick and choose the surface area of the API. But most people probably just want to sub-class the program entry-point for FluentMigrator.DotNet.Cli in order to get the benefits of MSBuild's ResolvePackageAssets task tree that generates a project.assets.json file at the end of your build, since that gets passed to the runtime to resolve link-load dependencies.