[Suggestion] [PR] Implement .NET Core support.

[bmarinov]

I wanted to start a discussion on the viability of a .NET Core version.

Earlier this week I posted a draft PR (#16) and from the looks of it its working fine. We did a couple of tests on our build agents and noticed no issues. At the same time our migration scripts are all generated by EF Core so we dont do anything too complex or weird there.

Maybe the best way forward would be to leave both console application projects in the solution and move all functionality to a Netstandard library. That way we will keep the classic framework application for Windows/Legacy projects and the .NET Core one for Linux (and Windows).

Let me know what you think :) if you like the idea I'll go ahead and push the changes adding the library to the solution.

Kind regards!

[SqlQuantumLeap]

@bmarinov Sorry to keep you waiting. Been busy. Will respond tomorrow with thoughts...

[bmarinov]

@SqlQuantumLeap no worries i've been swimming with work the last couple of days myself, so I can relate.
I also found a potential issue, we might not get away with duplicating some code. The issue is the SQL Client NuGet that is needed in core and the aforementioned missing/deprecated setting ( SqlConnectionStringBuilder.ContextConnection ).

If you want I can push some code so you can see how the end result would look like. Im mostly worried that the classic / Windows version will increase in size since we won't necessarily be relying on the SQL Client dependencies in the GAC. Maybe im wrong tho.

[SqlQuantumLeap]

@bmarinov Hello again. Some thoughts:

1. I love the idea of a .NET Core version and the ability to run on Linux as well as Windows.

2. My primary goal is that this just work as simply as possible, with hopefully no additional dependency installation needed. I haven't had time to get into .NET Core so I don't know if assemblies compiled against it run out of the box on Windows or if one needs to download the runtime MSI from Microsoft.com. Meaning, is there a downside to having only a .NET Core version? If .NET Core runs on Windows with no additional installs required, then perhaps we do that. But, if anything else is required, then I prefer to have it structured so that someone can select the configuration (Framework vs Core) in VS and build. I don't mind having compiler directives in the code so that we can maintain a single code base. I know some folks are against compiler directives, but if there are just minor differences between the builds, then I wouldn't want the hassle of synchronizing changes across multiple files that are largely the same. I use compiler directives in my SQL# project to toggle between Free and Full versions and they work great.

3. I have a few other utilities that I have been wanting to get running on Linux, so I would like to come up with a model here that can be applied to my other projects. The other projects are of similar size, or smaller (for example: BinaryFormatter ).

4. Will Visual Studio 2015 work for this?

5. Regarding SqlConnectionStringBuilder.ContextConnection: that can be removed entirely. It's just a safe-guard in case someone passed in the option, though I don't see why anyone would since the Context Connection is only valid in SQLCLR (hence why I'm turning it off no matter what). But, if need be, that line can easily be replaced with a RegEx.Replace() that replaces ContextConnection\s*=\s*true with an empty string. And that can even work in both versions (if we end up having two versions).

6. I'm not worried about the Windows version getting a little larger. A smaller executable is a bonus, but not the goal. Simplicity and no dependencies is the goal.

7. Thanks again for helping out with this 😺 .

[bmarinov]

@SqlQuantumLeap

2. Dependencies, Windows, .NET Framework:

• Regarding dependencies, AFAIK in order to execute the windows version you would need the .NET Core Runtime installed on the machine. Other than that there are no dependencies. Currently the Pull Request version requires dotnet core 2.1, but we can easily multitarget and depend on either 2.0, 2.1 or 2.2 :D
• I compiled and published the application targeting linux-x64, the CLI application runs without issues on Linux. The same published application can technically be executed on Windows, but this will probably cause a runtime exception due to platform-specific NuGet dependnecies.
  • In other words, the runtime identifier (e.g. win-x64, linux-x64 etc) needs to be set at the time of publishing. Same code, but platform-specific binaries.
  • Alternatively, a completely portable publish output can be generated. This will then include the platform-specific dependencies in their respective subdirectories (eg under /runtimes/unix/lib/...). You can test the output by playing with the settings in the Publish Profile dialog.
• The publish output can be run on Windows by either:
  • executing dotnet SimpleSqlExec.dll
  • or by setting the target runtime to windows and generating an .exe that can be then executed as usual.
• Most things can be preconfigured via publish profiles or command line arguments for the dotnet publish command.

3. IMO the best approach would be to move all code to a Netstandard (v2) library and call the public methods from a console application. From there it is easy to test "Classic" and Core side by side by having two console applications using the common netstd lib.

4. It seems that dotnet core can work on VS2017+. The main issue seems to be the new csproj format. I cannot test it myself as I dont have VS2015 installed anymore, but I still remember the pain of trying to use the new csproj format with PackageReference for the NuGet dependencies and it was a constant pain.

Actually, should I check in a couple of powershell scripts or the publish profiles so you have an easier time figuring out what im rambling about? 🔨

Cheers!