yevhen / Streamstone

Event store for Azure Table Storage
Other
395 stars 64 forks source link

Support .NET Core #28

Closed ChrisSimmons closed 7 years ago

ChrisSimmons commented 8 years ago

The primary pieces which I see as challenges on this:

I'll work on this and submit a PR. Unless of course someone else is working on this?

yevhen commented 8 years ago

Wow, awesome! That would be super cool.

I'm only worried about string-only queries. Will probably make my very beatiful code look uglier ๐Ÿ˜„ But I can live with that.

Anyway, looking forward to your PR!

yevhen commented 8 years ago

If you need any help or want to discuss we have a chat room here https://gitter.im/yevhen/Streamstone

ChrisSimmons commented 8 years ago

Indeed, it's breaking my heart seeing the clean LINQ turned into strings. But Microsoft does offer somewhat readable helper classes.

I'm admittedly not an expert at working with Core, but I'm hoping to get a passable equivalent and make all the tests pass.

Thanks, yes I'll ask questions on Gitter as I'm sure I'll have some...

yevhen commented 8 years ago

@ChrisSimmons looking at some of the commits I've noticed xproj and project.json. But isn't this thing is already dead according to this? https://blogs.msdn.microsoft.com/dotnet/2016/05/23/changes-to-project-json/

ChrisSimmons commented 8 years ago

@yevhen, good question. It does appear that Microsoft will move back to .csproj and MSBuild. However, *.xproj and project.json are what was part of .NET Core RTM at the end of June. A better way to say it is that it will be dead at the Visual Studio 15 RTM. Until then, we have *.xproj and project.json. The promise from Microsoft is that the projects will auto-convert then. It's either trust that or play it safe and avoid Core altogether until then. The more I work with this new framework, the more I lean toward avoid. The tooling is still buggy, half the 3rd-party tools I normally use (NCrunch, e.g.) simply don't support it, and you have issues like the slimmed-down Azure SDK.

With that said, I'm not seeing a clear path to make this thing actually .NET Core "compliant" in the short term. If you see my latest commit (862a245), I've got the majority of the tests passing. However, there are still 27 failing, 9 of which are legit test failures (e.g. "Expected 4 but was 9"). However the majority of are related to FileLoadExceptions as NUnit tries to load .NET 4.5 System assemblies. Before I blame the NUnit test runner or something else in the stack, I'll try some other approaches (e.g. see this).

But then I wonder if all this is even worth it. In order to get it to work, the main StreamStone project still has to have .NET 4.5 libraries pulled in inimports. i.e. it's not truly .NET Core in the end. This is primarily due to the Azure SDK support level.

So I'm going to pause for a bit and think before any more work on this.

ChrisSimmons commented 8 years ago

BTW, please forgive the high commit count. This is simply my method of work, breaking each commit into a "digestible bite" of work. I hate huge diffs, especially when they cover more than one logical change.

yevhen commented 8 years ago

Ok, make sense. Don't rush. Ye, it might be better to wait a bit until full Core support from AzureSDK and NUnit (ExpectedObjects could be substituted to FluentAssertions, but I'm not sure about support of Core in this testing library). Thanks for taking this effort!

yevhen commented 8 years ago

BTW, please forgive the high commit count. This is simply my method of work, breaking each commit into a "digestible bite" of work. I hate huge diffs, especially when they cover more than one logical change.

No problem at all - I use the same method. At the end - they could be squashed in a single commit anyways :)

ChrisSimmons commented 8 years ago

With this branch, I have the project running and all tests passing with very little change to the original code. The only change I made to actual code was to the test code, and then only for async things which changed in the latest NUnit.

The problem is that it's actually a "net461" project, not Core. And the other branch is also not actually Core. It wouldn't be cross-platform and will not be until the AzureSDK support catches up. The testing framework stuff can be worked around, but the Azure part can't be faked. Unless you want to start writing your own raw REST/OData stuff.

At this point, I agree that it's best to wait for better support from the key dependency: AzureSDK.

yevhen commented 8 years ago

Ok, let's leave this issue open and return it once AzureSDK is ready.

galvesribeiro commented 7 years ago

Hey guys, do we have any ETA on get .Net Core support for SS?

Azure SDK is long ago supported for .Net Core and we use in Orleans Port just fine. The major problem is NUnit that its dotnet cli support is broken since it doesn't support the "new" MSBuild projects yet and according to the project maintainers, there is no guarantee on get it to work soon https://github.com/nunit/dotnet-test-nunit/issues/91

I would suggest do what we did in Orleans.

  1. Make the Streamstone.csproj a netstandard1.5 project
  2. Keep the tests as a .Net 4.6.2 regular project.

So, for now, the tests would be made on Windows only but, as the code seems to not have any restrictive APIs being used and everything is portable, it could live while NUnit doesn't get dotnet cli support for MSBuild

Do you guys need any help with it? I just did it for Orleans so could help here.

I have complete interest to use SS on a new project I'm working in but I need to make a call quickly on which library I would use for ES store so I'm more than happy to help on this issue.

Thanks!

yevhen commented 7 years ago

Cool, help is very welcomed!

I like you your plan. We hit the wall with NUnit and stopped there. Also, AFAIK linq queries are not supported in Azure Core sdk.

Can't wait for you PR ๐Ÿ˜‹ !!!

galvesribeiro commented 7 years ago

@yevhen Look at #29 when you can. ๐Ÿ’ƒ

mmisztal1980 commented 7 years ago

@yevhen I was curious about this issue's progress? it's been 6 months since last comment was made? I take it it's not resolved yet?

galvesribeiro commented 7 years ago

@mmisztal1980 I'm waiting the nUnit to finish the .Net Core port (it is very close) so I can finish the migration here.

mmisztal1980 commented 7 years ago

Why not use xunit instead? It has supported netcore for a while now

Dnia 03.05.2017 o godz. 18:46 Gutemberg Ribeiro notifications@github.com napisaล‚(a):

@mmisztal1980 I'm waiting the nUnit to finish the .Net Core port (it is very close) so I can finish the migration here.

โ€” You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

galvesribeiro commented 7 years ago

@mmisztal1980 I made the same question before, I personally don't like nUnit and use xUnit all over the place, but that is a philosophical debate and I think we should avoid it :)

Lets just wait a bit more so nUnit release it (I'm monitoring closely the progress with their devs) and I can update the projects here.

mmisztal1980 commented 7 years ago

do you have an ETA from them?

galvesribeiro commented 7 years ago

They are going to release an stable-ish beta soon. When it is out, and if @yevhen agree on have the beta dependency on the tests, I can do the work.

I'm also interested on use it on .net core, believe me. I've keeping a custom local build here which is a nightmare to deal with versions and my CI environment. So trust me, I want it out asap...

yevhen commented 7 years ago

I think we can release beta package if you need it now

yevhen commented 7 years ago

@ChrisSimmons @galvesribeiro This is finally completed by @Soarc in #37, merge and pushed to nuget. Streamstone 2.0 built for netstandard 1.6/2.0. Thanks to all of you guys! Closing this issue.