New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for .NET Core #712

Closed
fubar-coder opened this Issue Mar 30, 2016 · 41 comments

Comments

Projects
None yet
@fubar-coder
Member

fubar-coder commented Mar 30, 2016

We should think about starting to support .NET Core as soon as RC2 is out and supported by VS 2015. With the change to a project.json, we're still able to target platforms like .NET 3.5/4 in addition to netstandard1.3 (or higher?).

Conversion steps:

  • Move from IDbConnection, etc to DbConnection
    • System.Data.Common is available since .NET 2.0
  • Remove the need for ICloneable
    Switching to immutable types?
  • Replace usage of DataSet

All this work shouldn't be done in a single step. It should be done in multiple pull requests (or a single pull request with squashed commits to have one commit per step) for easier code review.

@fubar-coder fubar-coder added the Task label Mar 30, 2016

@fubar-coder fubar-coder modified the milestone: vNext Mar 30, 2016

@eloekset

This comment has been minimized.

Show comment
Hide comment
@eloekset

eloekset Mar 30, 2016

Collaborator

#621 is also about this topic.

Collaborator

eloekset commented Mar 30, 2016

#621 is also about this topic.

@fubar-coder

This comment has been minimized.

Show comment
Hide comment
@fubar-coder

fubar-coder Mar 30, 2016

Member

We're tracking the progress here.

Member

fubar-coder commented Mar 30, 2016

We're tracking the progress here.

@dmirmilshteyn

This comment has been minimized.

Show comment
Hide comment
@dmirmilshteyn

dmirmilshteyn May 27, 2016

@fubar-coder Another factor to consider is integration with the dotnet CLI. It would be nice to be able to add a runner to the "tools" section of project.json, then execute commands such as "dotnet fm migrate [flags]". It would likely be as simple as renaming the current console runner to dotnet-fm and then packing it up in nuget. In the short term, to avoid breaking backwards compatibility, we can create a new runner project which references the console runner, and have the input forwarded to that until the next major release.

I've started working on a port with the RC2 bits, will have some PRs in shortly...

dmirmilshteyn commented May 27, 2016

@fubar-coder Another factor to consider is integration with the dotnet CLI. It would be nice to be able to add a runner to the "tools" section of project.json, then execute commands such as "dotnet fm migrate [flags]". It would likely be as simple as renaming the current console runner to dotnet-fm and then packing it up in nuget. In the short term, to avoid breaking backwards compatibility, we can create a new runner project which references the console runner, and have the input forwarded to that until the next major release.

I've started working on a port with the RC2 bits, will have some PRs in shortly...

@giggio

This comment has been minimized.

Show comment
Hide comment
@giggio

giggio Jul 26, 2016

Just FYI, I got my runner for .NET CLI for Fluent Migrator working. The license is compatible, you may want to take a look. I think that supporting .NET Core is very important, I am just posting this to help people who would like to use Fluent Migrator until this step is completed.
https://github.com/giggio/FluentMigrator.Runner.Cli

giggio commented Jul 26, 2016

Just FYI, I got my runner for .NET CLI for Fluent Migrator working. The license is compatible, you may want to take a look. I think that supporting .NET Core is very important, I am just posting this to help people who would like to use Fluent Migrator until this step is completed.
https://github.com/giggio/FluentMigrator.Runner.Cli

@jayalakshmis

This comment has been minimized.

Show comment
Hide comment
@jayalakshmis

jayalakshmis Oct 5, 2016

@giggio, do you by chance have a pull request out for merging this upstream?

jayalakshmis commented Oct 5, 2016

@giggio, do you by chance have a pull request out for merging this upstream?

@giggio

This comment has been minimized.

Show comment
Hide comment
@giggio

giggio Oct 6, 2016

I do not, but I could, if the maintainers are interested. Let me know.

giggio commented Oct 6, 2016

I do not, but I could, if the maintainers are interested. Let me know.

@ferodss

This comment has been minimized.

Show comment
Hide comment
@ferodss

ferodss Nov 9, 2016

Would be nice to have .NET Core support, any update?

ferodss commented Nov 9, 2016

Would be nice to have .NET Core support, any update?

@fubar-coder

This comment has been minimized.

Show comment
Hide comment
@fubar-coder

fubar-coder Nov 9, 2016

Member

I'm not sure how useful it'd be to convert FluentMigrator to netstandard < 2.0, because netstandard2.0 reintroduces many APIs that are used by FluentMigrator.

Member

fubar-coder commented Nov 9, 2016

I'm not sure how useful it'd be to convert FluentMigrator to netstandard < 2.0, because netstandard2.0 reintroduces many APIs that are used by FluentMigrator.

@ferodss

This comment has been minimized.

Show comment
Hide comment
@ferodss

ferodss Nov 9, 2016

So no .NET Core support for the next 6 months? For sure it would be useful

See the roadmap https://github.com/dotnet/core/blob/master/roadmap.md#ship-dates

ferodss commented Nov 9, 2016

So no .NET Core support for the next 6 months? For sure it would be useful

See the roadmap https://github.com/dotnet/core/blob/master/roadmap.md#ship-dates

@dmirmilshteyn

This comment has been minimized.

Show comment
Hide comment
@dmirmilshteyn

dmirmilshteyn Nov 10, 2016

If you need something more quickly, I've got it working a while ago on .NET Core (netstandard1.3) without Mono: https://github.com/dmirmilshteyn/fluentmigrator/tree/core-rtm. It's been working fine xplat for me. The big limitation for getting this ported is the database drivers themselves - when I did the initial port, only Npgsql really had any support for .NET Core, so my repo only supports Postgres.

dmirmilshteyn commented Nov 10, 2016

If you need something more quickly, I've got it working a while ago on .NET Core (netstandard1.3) without Mono: https://github.com/dmirmilshteyn/fluentmigrator/tree/core-rtm. It's been working fine xplat for me. The big limitation for getting this ported is the database drivers themselves - when I did the initial port, only Npgsql really had any support for .NET Core, so my repo only supports Postgres.

govorovvs added a commit to govorovvs/fluentmigrator that referenced this issue Dec 23, 2016

@govorovvs

This comment has been minimized.

Show comment
Hide comment
@govorovvs

govorovvs Dec 26, 2016

Hi, guys! What do you think about splitting FluentMigrator into many small Nuget-packages: Core, SqlServer, Firebird etc. At current moment not all supported DB have netstandard drivers. Splitting can help us to migrate to netstandart step by step.

govorovvs commented Dec 26, 2016

Hi, guys! What do you think about splitting FluentMigrator into many small Nuget-packages: Core, SqlServer, Firebird etc. At current moment not all supported DB have netstandard drivers. Splitting can help us to migrate to netstandart step by step.

@DustinVenegas

This comment has been minimized.

Show comment
Hide comment
@DustinVenegas

DustinVenegas Dec 26, 2016

DustinVenegas commented Dec 26, 2016

@DukeCheng

This comment has been minimized.

Show comment
Hide comment
@DukeCheng

DukeCheng Jan 5, 2017

Is there any development version publish on myget?

DukeCheng commented Jan 5, 2017

Is there any development version publish on myget?

@giggio giggio referenced this issue Jan 8, 2017

Open

`migrate` #19

@volkanceylan

This comment has been minimized.

Show comment
Hide comment
@volkanceylan

volkanceylan Jan 11, 2017

With some help from commits by @dmirmilshteyn in his fork and a few other fixes, i've succesfully ported a small part of FluentMigrator to .NET Core/Standard. I tested it with Sql Server. others might run as well, but couldn't try them yet.

I've only ported FluentMigrator and FluentMigrator.Runner as these are only the ones i currently use with my app platform, Serenity. I may work on others e.g. FluentMigrator.Console etc, if required.

Please note that this is just a temporary port until an official version comes out. I couldn't wait more as Serenity Asp.Net Core version will be out soon and it depends heavily on FluentMigrator.

Here are the links to packages and code

https://www.nuget.org/packages/Serenity.FluentMigrator
https://www.nuget.org/packages/Serenity.FluentMigrator.Runner
https://github.com/volkanceylan/fluentmigrator

volkanceylan commented Jan 11, 2017

With some help from commits by @dmirmilshteyn in his fork and a few other fixes, i've succesfully ported a small part of FluentMigrator to .NET Core/Standard. I tested it with Sql Server. others might run as well, but couldn't try them yet.

I've only ported FluentMigrator and FluentMigrator.Runner as these are only the ones i currently use with my app platform, Serenity. I may work on others e.g. FluentMigrator.Console etc, if required.

Please note that this is just a temporary port until an official version comes out. I couldn't wait more as Serenity Asp.Net Core version will be out soon and it depends heavily on FluentMigrator.

Here are the links to packages and code

https://www.nuget.org/packages/Serenity.FluentMigrator
https://www.nuget.org/packages/Serenity.FluentMigrator.Runner
https://github.com/volkanceylan/fluentmigrator

@rhegner

This comment has been minimized.

Show comment
Hide comment
@rhegner

rhegner Jan 12, 2017

@volkanceylan I tried your fork and it seems to work fine with MySQL and SQL Server. Thanks for sharing! Let's hope we'll see .Net Core support in the official release soon...

rhegner commented Jan 12, 2017

@volkanceylan I tried your fork and it seems to work fine with MySQL and SQL Server. Thanks for sharing! Let's hope we'll see .Net Core support in the official release soon...

@escarls

This comment has been minimized.

Show comment
Hide comment
@escarls

escarls Feb 24, 2017

Collaborator

The current Travis build will not support .NET core.
Working on upgrading the builds, so it can run on newer Travis workers that supports both NuGet restore and .NET Core.

Collaborator

escarls commented Feb 24, 2017

The current Travis build will not support .NET core.
Working on upgrading the builds, so it can run on newer Travis workers that supports both NuGet restore and .NET Core.

@DustinVenegas

This comment has been minimized.

Show comment
Hide comment
@DustinVenegas

DustinVenegas Feb 28, 2017

@escarls - I was thinking AppVeyor; did you have a different direction you were thinking?

Note with with the project.json to *.csproj changes coming for VS2017 we might jump on the 2017 train and get moved to *.csrpoj files now.

DustinVenegas commented Feb 28, 2017

@escarls - I was thinking AppVeyor; did you have a different direction you were thinking?

Note with with the project.json to *.csproj changes coming for VS2017 we might jump on the 2017 train and get moved to *.csrpoj files now.

@escarls

This comment has been minimized.

Show comment
Hide comment
@escarls

escarls Mar 1, 2017

Collaborator

@DustinVenegas I haven't thought about anything like that yet. I was just thinking about #738 firstly and that maybe it would be easier to move to dotnet core if everything was just a single build system first :)
That said, I tried to build FluentMigrator in AppVeyor yesterday. It builds, but it give a lot of errors on the unit tests. :)

Collaborator

escarls commented Mar 1, 2017

@DustinVenegas I haven't thought about anything like that yet. I was just thinking about #738 firstly and that maybe it would be easier to move to dotnet core if everything was just a single build system first :)
That said, I tried to build FluentMigrator in AppVeyor yesterday. It builds, but it give a lot of errors on the unit tests. :)

@Izzmo

This comment has been minimized.

Show comment
Hide comment
@Izzmo

Izzmo Mar 23, 2017

So, 2017 is released. Any status update on this?

Izzmo commented Mar 23, 2017

So, 2017 is released. Any status update on this?

@fubar-coder

This comment has been minimized.

Show comment
Hide comment
@fubar-coder

fubar-coder Mar 23, 2017

Member

@dmirmilshteyn and @volkanceylan already made the conversion, but I didn't have a chance to look at it yet.

Member

fubar-coder commented Mar 23, 2017

@dmirmilshteyn and @volkanceylan already made the conversion, but I didn't have a chance to look at it yet.

@Izzmo

This comment has been minimized.

Show comment
Hide comment
@Izzmo

Izzmo Mar 23, 2017

Awesome, I see his comment above. Thanks @fubar-coder , I'll check out his packages and see if I can test them out on our new core project.

Izzmo commented Mar 23, 2017

Awesome, I see his comment above. Thanks @fubar-coder , I'll check out his packages and see if I can test them out on our new core project.

@eloekset

This comment has been minimized.

Show comment
Hide comment
@eloekset

eloekset Mar 23, 2017

Collaborator

@fubar-coder why not start a new branch for this so it's easier to contribute progress on this task? I've pulled from @volkanceylan's fork and upgraded to the new .csproj project format for VS2017 in this branch: https://github.com/eloekset/fluentmigrator/tree/dev_VS2017

But I can't send a PR to be merged to master, so maybe you can create new branch in this repo and create a PR from my branch into the new one?

Collaborator

eloekset commented Mar 23, 2017

@fubar-coder why not start a new branch for this so it's easier to contribute progress on this task? I've pulled from @volkanceylan's fork and upgraded to the new .csproj project format for VS2017 in this branch: https://github.com/eloekset/fluentmigrator/tree/dev_VS2017

But I can't send a PR to be merged to master, so maybe you can create new branch in this repo and create a PR from my branch into the new one?

@fubar-coder

This comment has been minimized.

Show comment
Hide comment
@fubar-coder

fubar-coder Mar 23, 2017

Member

@eloekset I created a feature/dotnet-core branch

Member

fubar-coder commented Mar 23, 2017

@eloekset I created a feature/dotnet-core branch

@PeterKnealeNearmap

This comment has been minimized.

Show comment
Hide comment
@PeterKnealeNearmap

PeterKnealeNearmap Aug 19, 2017

dotnet core 2 is out now. Does targeting that make this task easier?

PeterKnealeNearmap commented Aug 19, 2017

dotnet core 2 is out now. Does targeting that make this task easier?

@PeterKneale

This comment has been minimized.

Show comment
Hide comment
@PeterKneale

PeterKneale Aug 20, 2017

FYI: I'm using FluentMigrator 1.6.2 upon .NET Core 2.0 via the docker containers microsoft/aspnetcore-build:2 and microsoft/aspnetcore:2 against library/postgres using Npgsql 3.2.5 and my first few migrations are running well.
I do receive the below warnings which is expected.
warning NU1701: Package 'FluentMigrator 1.6.2' was restored using '.NETFramework,Version=v4.6.1' instead of the project target framework '.NETCoreApp,Version=v2.0'. This package may not be fully compatible with your project.

PeterKneale commented Aug 20, 2017

FYI: I'm using FluentMigrator 1.6.2 upon .NET Core 2.0 via the docker containers microsoft/aspnetcore-build:2 and microsoft/aspnetcore:2 against library/postgres using Npgsql 3.2.5 and my first few migrations are running well.
I do receive the below warnings which is expected.
warning NU1701: Package 'FluentMigrator 1.6.2' was restored using '.NETFramework,Version=v4.6.1' instead of the project target framework '.NETCoreApp,Version=v2.0'. This package may not be fully compatible with your project.

@eloekset

This comment has been minimized.

Show comment
Hide comment
@eloekset

eloekset Aug 20, 2017

Collaborator

I think, as soon as the build environment supports .NET Core 2.0, we should try converting the csproj files and output nupacks on build which target net452,net462,net471,netstandard2.0 without making any changes to the code in a new branch from master. If that works fine, we can save us from some clutter to support netstandard1.X, and still support all new projects on .NET Core 2.0.

Collaborator

eloekset commented Aug 20, 2017

I think, as soon as the build environment supports .NET Core 2.0, we should try converting the csproj files and output nupacks on build which target net452,net462,net471,netstandard2.0 without making any changes to the code in a new branch from master. If that works fine, we can save us from some clutter to support netstandard1.X, and still support all new projects on .NET Core 2.0.

@cdroulers

This comment has been minimized.

Show comment
Hide comment
@cdroulers

cdroulers Aug 21, 2017

@PeterKneale How do you run your migrations? I've a project with migrations that compiles well, but (obivously) migrate.exe won't load the DLL compiled to netstandard2 or netcoreapp2. Any pointers?

cdroulers commented Aug 21, 2017

@PeterKneale How do you run your migrations? I've a project with migrations that compiles well, but (obivously) migrate.exe won't load the DLL compiled to netstandard2 or netcoreapp2. Any pointers?

@PeterKnealeNearmap

This comment has been minimized.

Show comment
Hide comment
@PeterKnealeNearmap

PeterKnealeNearmap Aug 22, 2017

@cdroulers See below. You can call it from your own netcoreapp2 executable (or webapp or integration tests etc).

    public class Migrate
    {
        public static void Up(string connectionString)
        {
            var announcer = new TextWriterAnnouncer(s => System.Diagnostics.Debug.WriteLine(s));
            var assembly = Assembly.GetExecutingAssembly();

            var migrationContext = new RunnerContext(announcer);
            var options = new MigrationOptions { PreviewOnly = false, Timeout = 60 };
            var factory = new PostgresProcessorFactory();
            using (var processor = factory.Create(connectionString, announcer, options))
            {
                var runner = new MigrationRunner(assembly, migrationContext, processor);
                runner.MigrateUp(true);
            }
        }
    }

    class MigrationOptions : IMigrationProcessorOptions
    {
        public bool PreviewOnly { get; set; }
        public string ProviderSwitches { get; set; }
        public int Timeout { get; set; }
    }

PeterKnealeNearmap commented Aug 22, 2017

@cdroulers See below. You can call it from your own netcoreapp2 executable (or webapp or integration tests etc).

    public class Migrate
    {
        public static void Up(string connectionString)
        {
            var announcer = new TextWriterAnnouncer(s => System.Diagnostics.Debug.WriteLine(s));
            var assembly = Assembly.GetExecutingAssembly();

            var migrationContext = new RunnerContext(announcer);
            var options = new MigrationOptions { PreviewOnly = false, Timeout = 60 };
            var factory = new PostgresProcessorFactory();
            using (var processor = factory.Create(connectionString, announcer, options))
            {
                var runner = new MigrationRunner(assembly, migrationContext, processor);
                runner.MigrateUp(true);
            }
        }
    }

    class MigrationOptions : IMigrationProcessorOptions
    {
        public bool PreviewOnly { get; set; }
        public string ProviderSwitches { get; set; }
        public int Timeout { get; set; }
    }
@elevate-andrewlock

This comment has been minimized.

Show comment
Hide comment
@elevate-andrewlock

elevate-andrewlock Sep 25, 2017

I was just wondering what is left to be done to get a netstandard build of FluentMigrator?

I've run the portability analyzer on the dotnet-core branch, and there's no issues there (one false positive, but nothing to worry about), but I notice the various runners and test project aren't part of the solution.

The fact @PeterKnealeNearmap can run migrations gets no issues in a netcoreapp build is very promising, but would be good to have a true netstandard build rather than having to use the compat shim.

Is anyone actively working on this at the moment?

Thanks

elevate-andrewlock commented Sep 25, 2017

I was just wondering what is left to be done to get a netstandard build of FluentMigrator?

I've run the portability analyzer on the dotnet-core branch, and there's no issues there (one false positive, but nothing to worry about), but I notice the various runners and test project aren't part of the solution.

The fact @PeterKnealeNearmap can run migrations gets no issues in a netcoreapp build is very promising, but would be good to have a true netstandard build rather than having to use the compat shim.

Is anyone actively working on this at the moment?

Thanks

@eloekset

This comment has been minimized.

Show comment
Hide comment
@eloekset

eloekset Sep 27, 2017

Collaborator

I haven't been working on this in a long time. It's possible for anyone to continue on the dotnet-core branch and port and run tests to verify the correctness of the tweaks that have been done. Keep in mind that the work was meant as temporary solution for Serenity until an official port was done, so we'll need to test everything well before merging into the master branch.

Collaborator

eloekset commented Sep 27, 2017

I haven't been working on this in a long time. It's possible for anyone to continue on the dotnet-core branch and port and run tests to verify the correctness of the tweaks that have been done. Keep in mind that the work was meant as temporary solution for Serenity until an official port was done, so we'll need to test everything well before merging into the master branch.

@black-byte

This comment has been minimized.

Show comment
Hide comment
@black-byte

black-byte Nov 10, 2017

Any news in this topic ? Any plans to realase working version of fluent migrator on .net core 2.0 ?

black-byte commented Nov 10, 2017

Any news in this topic ? Any plans to realase working version of fluent migrator on .net core 2.0 ?

@pfeigl

This comment has been minimized.

Show comment
Hide comment
@pfeigl

pfeigl Nov 19, 2017

This would be great, are there any areas where one can contribute to bring this into a working state?

pfeigl commented Nov 19, 2017

This would be great, are there any areas where one can contribute to bring this into a working state?

@kcrossman

This comment has been minimized.

Show comment
Hide comment
@kcrossman

kcrossman Jan 19, 2018

It's been several months since I've seen any updates on this. Please continue to upgrade Fluent to .NET Standard 2 so I don't feel dirty for putting .NET Framework projects in my mostly .NET Core/Standard 2 solution. :)

kcrossman commented Jan 19, 2018

It's been several months since I've seen any updates on this. Please continue to upgrade Fluent to .NET Standard 2 so I don't feel dirty for putting .NET Framework projects in my mostly .NET Core/Standard 2 solution. :)

@eloekset

This comment has been minimized.

Show comment
Hide comment
@eloekset

eloekset Feb 4, 2018

Collaborator

Someone following this issue have a clue about ruby?
image

Collaborator

eloekset commented Feb 4, 2018

Someone following this issue have a clue about ruby?
image

@escarls

This comment has been minimized.

Show comment
Hide comment
@escarls

escarls Feb 5, 2018

Collaborator

What Ruby version are you running and could you please do a gem list and paste?

Collaborator

escarls commented Feb 5, 2018

What Ruby version are you running and could you please do a gem list and paste?

@haf

This comment has been minimized.

Show comment
Hide comment
@haf

haf Feb 5, 2018

You should know v3 of albacore supports .Net Core out of the box.

Also, I'm planning on ramping down my maintenance of albacore. I strongly suggest you move to FAKE.

Also, you can have a look at https://github.com/haf/expecto/ for a really good example of building for .Net core.

haf commented Feb 5, 2018

You should know v3 of albacore supports .Net Core out of the box.

Also, I'm planning on ramping down my maintenance of albacore. I strongly suggest you move to FAKE.

Also, you can have a look at https://github.com/haf/expecto/ for a really good example of building for .Net core.

@eloekset

This comment has been minimized.

Show comment
Hide comment
@eloekset

eloekset Feb 5, 2018

Collaborator

@escarls here is a dump of gem list and ruby --version:
image
According to the prerequisites, I should use ruby 2.2.4, but I found 2.2.6 at the download page, so I guess that's a compatible but better version.

I've also got Ubuntu and macOS environments if ruby works better there.

@haf, if you scroll up this issue, you'll see a move to AppVeyor was suggested about a year ago. I've seen another project (can't remember which one) was built with AppVeyor, and it was very easy to do .NET CLI there. I think that's the way to go, if we decide to drop support for .NET 3.5 and use only .NET Standard projects with <TargetFrameworks>net452;netstandard2.0</TargetFrameworks>.

Collaborator

eloekset commented Feb 5, 2018

@escarls here is a dump of gem list and ruby --version:
image
According to the prerequisites, I should use ruby 2.2.4, but I found 2.2.6 at the download page, so I guess that's a compatible but better version.

I've also got Ubuntu and macOS environments if ruby works better there.

@haf, if you scroll up this issue, you'll see a move to AppVeyor was suggested about a year ago. I've seen another project (can't remember which one) was built with AppVeyor, and it was very easy to do .NET CLI there. I think that's the way to go, if we decide to drop support for .NET 3.5 and use only .NET Standard projects with <TargetFrameworks>net452;netstandard2.0</TargetFrameworks>.

@haf

This comment has been minimized.

Show comment
Hide comment
@haf

haf Feb 5, 2018

@eloekset Yes, what you're listing there shows I'm right about what I said above.

<TargetFrameworks>net461;netstandard2.0</TargetFrameworks> is what I've moved to for all my projects.

If you have a look at the linked project, you'll find it's indeed very simple to build both on linux/osx and windows with the build infra there.

haf commented Feb 5, 2018

@eloekset Yes, what you're listing there shows I'm right about what I said above.

<TargetFrameworks>net461;netstandard2.0</TargetFrameworks> is what I've moved to for all my projects.

If you have a look at the linked project, you'll find it's indeed very simple to build both on linux/osx and windows with the build infra there.

@AeonLucid

This comment has been minimized.

Show comment
Hide comment
@AeonLucid

AeonLucid Feb 20, 2018

Any ETA on an official netstandard 2.0 release?
Tried switching from an older version to the dotnet-core branch but it gave me a bit of trouble.

i.e.: The transaction passed to action given in WithConnection is null.
image

Any idea what's happening here?

AeonLucid commented Feb 20, 2018

Any ETA on an official netstandard 2.0 release?
Tried switching from an older version to the dotnet-core branch but it gave me a bit of trouble.

i.e.: The transaction passed to action given in WithConnection is null.
image

Any idea what's happening here?

@eloekset

This comment has been minimized.

Show comment
Hide comment
@eloekset

eloekset Feb 20, 2018

Collaborator

The dotnet-core branch may potentially have issues like this, since the code has been modified a lot to compile against .NET Standard without testing.

Although I haven't tested the feature branch I'm working on to port to .NET Standard 2.0, I'll recon it's much safer to use. Almost no changes was needed to support .NET Standard 2.0, but only core and runner projects are ported. The branch I'm talking about is the one used for this PR: #832

It should be tested, and the build stuff that generates NuGet packages for release doesn't bundle the .NET Standard libraries. So I'll either need help to make the existing Ruby build script work, or I'll have to make a new release script using tools I know. If you just want to build a .NET Standard 2.0 version, the NuGet-packages are built automatically using the .NET CLI, so you can "release" them in a private NuGet-feed or local folder.

Collaborator

eloekset commented Feb 20, 2018

The dotnet-core branch may potentially have issues like this, since the code has been modified a lot to compile against .NET Standard without testing.

Although I haven't tested the feature branch I'm working on to port to .NET Standard 2.0, I'll recon it's much safer to use. Almost no changes was needed to support .NET Standard 2.0, but only core and runner projects are ported. The branch I'm talking about is the one used for this PR: #832

It should be tested, and the build stuff that generates NuGet packages for release doesn't bundle the .NET Standard libraries. So I'll either need help to make the existing Ruby build script work, or I'll have to make a new release script using tools I know. If you just want to build a .NET Standard 2.0 version, the NuGet-packages are built automatically using the .NET CLI, so you can "release" them in a private NuGet-feed or local folder.

@fubar-coder

This comment has been minimized.

Show comment
Hide comment
@fubar-coder

fubar-coder Mar 31, 2018

Member

Support for .NET Standard 2.0 is implemented in release/2.0.0. It's not worth the hassle to support older .NET Standard versions,

Member

fubar-coder commented Mar 31, 2018

Support for .NET Standard 2.0 is implemented in release/2.0.0. It's not worth the hassle to support older .NET Standard versions,

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment