Multitargeting `EventStore.Client` package for both `netstandard2.0` and `net`

[enricosada]

It's possibile to have a single nuget package for the eventstore client api, using multitargeting instead of the two separate EventStore.ClientAPI and EventStore.ClientAPI.NetCore?

i volounteer to help with that, just need to discuss what do you prefer

That will fix:

• multi targeting projects who reference both netstandard (in a project reference) and .net in the main. Atm is really hard to do, because EventStore.ClientAPI.NetCore will be used in the p2p reference with netstandard, and EventStore.ClientAPI in the main project, so types will be bound to different assemblies

That will help:

• discoverability
• maintenance for users, using same package version inside the project
• maintenance for library authors who already implement multitargeting and depends on eventstore client for both netstandard and .net
• templates
• easier diff of api changes

May i ask why a separate repository for .net standard? The reason it's to not upgrade to latest sdk (old csproj) in https://github.com/EventStore/EventStore/ repo?

There are some options to minimize that friction:

• add new csproj in original repo, in parallel directory but referencing same sources
• generate net package as usual, and dotnet pack the new netstandard
• unify the packages at the end with a cli tool https://www.nuget.org/packages/dotnet-mergenupkg/

ref https://github.com/EventStore/ClientAPI.NetCore/issues/31

[megakid]

This would be good.

The EventStore.ClientAPI can target netstandard2.0 and net46 (and maybe netcoreapp2.1 if we want to have some #ifdefs to use fancy new .NET core features). I don't think I've seen any issues with the EventStore.ClientAPI.NetCore (or major differences in the code) so, as you say, it must be tooling that is the blocker for integration.

[enricosada]

@gregoryyoung is that fine for you? i'll send a PR with new .net core sdk project in parallel to existing codebase, and merge packages at end of build script. That allow to maintain current projects for net4*, with minimal maintenance, without go all-in with new sdk

[gregoryyoung]

:+1:

[p10tyr]

Has this been merged? Why is this closed?

I am facing this issue now where I want to use EmbeddedClient which is 4.6.1 but I did all my Architecture using EventStore.ClientApi.Core - My Architecture code needs IEventStoreConnection which is in both packages.

Installing both packages causes namespace hell. I tried to create external alias for one DLL which I thought would just work if I casted one to the other.. But that was asking for too much.

Is there a workaround??

How do I use EmbeddedClient with a DotnetStandard Library? (which relies on EventStore.ClientApi.Core)

I would like to pass in the IEventStoreConnection or something that will let the other client connect and do its thing.

[gregoryyoung]

"Has this been merged? Why is this closed?"

@ppumkin its not closed I am not sure why you believe it to be closed?

[megakid]

@enricosada do you have any movement on this? Would be interesting to see a draft of your proposal even if it's not complete?

[p10tyr]

OK I see the ticket number is different but its the same title? I thought it was referring to THIS one being closed.. that is why 🎃

Any way for now, I changed my CORE project to reference the 4.6.1 Packages - Its gives me a warning but everything seems to work OK. I suppose there may be a problem if I try to deploy it to Linux or something but for now it works OK for me... (after saving this post I will probably find out some issue)

But yea this is quite confusing ☹️

[enricosada]

@megakid I'll send a PR soon

[enricosada]

wip in https://github.com/EventStore/EventStore/pull/1680

[shaan1337]

As from version 5.0.0, EventStore.Client now targets both netstandard 2.0 and net46.