2.0 Thoughts

[bretcope]

There are two projects in Mayflower. One is a library (Mayflower) which provides all of the core functionality. The other is MayflowerCLI which generates the executable mayflower.exe. I'll address each one separately.

Mayflower (Library)

This project should be converted to target .NET Standard 1.3. I say 1.3 because that's the highest version implemented by both .NET Core 1.0 and .NET Framework 4.6. I don't think this will be difficult at all. The project has literally zero nuget dependencies currently, and it doesn't use any reflection or platform-specific features that I can think of. I'll give it a shot this weekend.

API

I'd like to take another look at the use cases for calling the library directly (as opposed to using the CLI) and reexamine what the API should look like. I wouldn't rule out the possibility of a major redesign before 1.0.

MayflowerCLI

I would actually like to work on compiling this with .NET Native. Right now I do an embedded resource trick to include the Mayflower.dll inside the exe, but the exe itself still requires .NET Framework 4.6 be installed on the machine. If we could compile a native exe, that would no longer be an issue.

I've only just started looking into how to use .NET Native, but since there's no JIT, my impression is that you can't emit IL at runtime. Last night, I got rid of the Dapper dependency in anticipation of that limitation.

It warrants more investigation. Hopefully it's not a big undertaking. If it is, we could revert back to the embedded resource approach for the time being. The code would be a little different in .NET Standard because AppDomains are gone, but I'm pretty sure it's still possible to dynamically load dll's from embedded resources.

Tests

We'll also need a third project for tests. NUnit's .NET Standard support was still in beta last I checked, but there are probably work arounds.

[bretcope]

Converting the library to .NET Standard 1.4 was pretty painless. The only real changes required were using MD5 instead of MD5CryptoServiceProvider, and the AssemblyInfo.cs is gone, so I'll have to circle back on versioning. I also need to circle back on setting up the nuget package, since nuspec is going away in favor of putting that info in the csproj.

Nothing's pushed yet, but probably today or tomorrow.

Next up, I'm going to look at converting the CLI project to something that is .NET Native compatible.

[bretcope]

I picked .NET Standard 1.4 instead of 1.3 since I think it's reasonable to expect .NET Framework 4.6.1. Microsoft says that's the most commonly targeted version.

[bretcope]

It looks like .NET Native is still only for UWP, which isn't going to work for a console app. So, I'm thinking the next best thing is to do a self-contained .NET Core executable. Investigating that now.

[bretcope]

I pushed what I have to the netstandard branch. It has several breaking interface changes in addition to just being ported to .NET Standard.

There is no CLI in the repo currently. I moved all of the logic for a CLI into the library itself, so all you'd have to write to have a fully-functioning console app is:

static int Main(string[] args)
{
    return Mayflower.Cli.Execute(args, Console.Out) ? 0 : 1;
}

I'm thinking about doing the console app(s) as a separate repo and nuget package which would depend on the library nuget. This would make it easier to support different deployment models (.NET Framework, .NET Core, .NET Core self-contained). Haven't totally decided the direction here yet.

I decided to completely revamp the command line arguments names. I got rid of all of the short-form aliases (e.g. -c), and shortened some of the long-form ones (e.g. --connection became --conn). I like this better because now there's exactly one way to specify each argument. If anyone is using the current CLI, they'll have some adjustments to make.

In theory, the library works, but I haven't really tested anything yet. I'm trying to get AppVeyor setup correctly to build the thing with all of the build tools changes.

Lastly, I just realized that apparently 1.0 was already published on Nuget, so I'm changing this to "2.0 Thoughts". I had never intended to consider this stable yet.

[bretcope]

More changes planned: #3, #4, #5, and #6.