Closed galvesribeiro closed 7 years ago
Ok, got some time to review the changes.
1) I don't have VS2017 on any of my machines and don't plan to install it until RTM. So first wrong thing - is that I can't open it in VS2015, which is bad :( I think other ppl could be in the same boat as me so we need to think how to handle this. If that could be only open in VS17, then it's better to create a separate branch, which will live until VS2017 RTM and all .NET Core releases will be delivered out of it. 2) Since sync calls are not supported by Azure Core SDK then sync versions of methods need to be removed as well. It means that V1.x of Streamstone will stay on .NET 4.X and V2.x and above will be released exclusively for .NET Standard. In such way breaking changes and dependency trade-offs will be obvious to end-users and we won't sink in multi-targeting mess (until .NET xplat dust is set) 3) All projects including test project should have a single target (.NETStandard or whatever netcoreapp1, I compeltely lost in framework subset (re)brandings). 4) Build/release part need to be updated/intergrated. Build scripts (Nake.bat) need to be changed so all of the tasks work as they do with current version. Perhaps, they could simply call dotnet cli for some parts and do rest of the things (which are not currently supported by cli, such as running nunit tests) 5) I guess the problem with NUnit should go away once all projects are on the same target, plus running nunit test runner via Nake.bat task should solve the problem of dotnet cli support from NUnit.
@galvesribeiro Does it make sense?
The branch is https://github.com/yevhen/Streamstone/tree/v20netstd
@yevhen LGTM. I'll close this PR and make a new one to the new branch. I sill need help from someone that knows NUnit better than me.
Thanks
This is PR try to make Streamstone a
netstandard1.5
library so it can run in .Net Core.The approach taken is basically the same we did in Orleans.
For now, I created a new solution and replicated the 3 projects in it but using links to the files in the current directories just to facilitate the changes in it.
So, major changes:
netstandard
version ofWindowsAzure.Storage
there is no sync methods anymore, so whenever I saw a sync method, I replaced with theXXXAsync()
related version. suggestion: I would remove all the Sync methods from the SS APIs and expose only the async ones and let the user call.Wait()
or.Result
in it.Example
project is now a .Net Core console app -> We can multitarget it in case we really need but I guess it is not necessaryGetType().SomethingElse
where replaced toGetType().GetTypeInfo().SomethingElse
since many methods were moved there.lambda -> string
queries since they are all good. Thanks @chrissimmons for already started that work.Streastone
project is now anetstandard1.5
project.net462
. The reason for that, is that NUnit does not work withdotnet
CLI yet and there is no estimated date to do so. I think the code on SS is very lean and simple, so at least for now, the tests running only onnet462
should be OK since there is noforking
or#if
whatsoever inside the code, so when NUnit got support to it, we could just migrate it.I need some help with NUnit just to make it detect the tests on VS TestExplorer and @aprooks will have a look in it later on.
Besides that, the
Example
app run perfectly, so I appreciate @yevhen and the others if I can have a review here.Once you guys give an OK, I would revert/reset the changes at the PR and apply them to the main solution/projects, update the build scripts along with the .nuspec, and push the updates here.
Thanks! Looking forward to use SS in .Net Core with Orleans ASAP!
💃
PS: Please note that appveyor build will fail. It will only pass once I update the main solution/project and the build scripts.