dapr / dotnet-sdk Goto Github PK

Currently in the actor remoting based request, the exception is thrown as Aggregate exception which is not adhering to new async/await pattern. The exception should be thrown as unwrapped to the client.

Update AspnetCore integration to handle namechange

need support from runtime dapr/dapr#27

Describe the proposal

Add following runtime components to SDK:

1. Actor registration.
2. Actor activation/deactivation.
3. Method invocation.
4. Reminder/Timer firing.
5. Actor state management.
6. Add routes for activation, deactivation, method, reminder, timer invocation.

For public preview, we need to publish nuget pkg to nuget.org.

• - Review OSS pkg release - https://devdiv.visualstudio.com/DevDiv/_wiki/wikis/DevDiv.wiki?pagePath=%2FProduct%20Development%20Reference%2FNuGet&pageId=972&wikiVersion=GBwikiMaster
• - Publish nuget package to nuget.org

needs runtime support dapr/dapr#21

Update icons in nugets to dapr icon

Regardless of language, anyone who use dotnet core can use dapr cs-sdk so it makes sense to rename the repo from cs-sdk to dotnet-sdk

currently the code throws the exception directly on the client side which rewrites the call stack, the code should wrap the exception in another Exception.
Alternatively an Aggregate Exception can also be thrown with the actual exception as its inner exception. Since user code awaits on tasks, throwing AggregateExceptions will not be right thing to do as await should not throw AggregateException and instead unwrap.

after move to .netcore 3.0, remove usage of NewtonsoftJson and use System.Text.Json so that Microsoft.Actions.Actors package has no external pkg dependency.

Split nuget package into Actors and Actors.AspNetcore so that client side code doesn't need to depend on AspNetcore.

Handle the changes in SDK for runtime behavior change dapr/dapr#219

Add non-RPC calls using ActorProxy., this allows for cross-language/direct-http of Actors methods.

Dapr sends events for topics in a cloudevent format, aspnetcore integration should handle it.

This allows calls into actors sdk to participate into Distributed Tracing.

Serialize actor state as json by default, currently the state is DataContract serializable to follow the Service Fabric reliable Actor models. Change the behavior to serialize state as json and consider adding a compatibility option as an attribute on Actor type for allowing Data Contract serialization for state so that SF Reliable Actors can also run using Dapr

Proposal: This is the proposal to build cs-sdk for .netcore 3.0 only
This would put us on the most latest release for .netcore.

What it means for users: This would mean that user applications have to be built with .netcore 3.0. They will not be able to build full framework version.

What it means for partners during private preview: Since .netcore 3.0 is in preview, partners will have to install preview versions of .netcore 3.0 and preview versions of VS 2019 which support .netcore 3.0. It should be available in 1st week of Sept 2013 in VS 2019.

Cons: Users must target apps for .net core 3.0 (and higher), https://github.com/dotnet/standard/blob/master/docs/versions.md). This means that .net full framework apps cannot be developed using the sdk. .netcore 3.0 would be released in November and is currently in preview.

Pros: Puts us on the latest netcore version and only target .netcore workloads. If we build for .netstandard 2.0, we will have to continue to support it for the foreseeable future which would put extra burden on the team since .Net Framework will not support newer .netstandard versions.
gRPC is supported in aspnetcore starting with aspnetcore 3.0

Amount of work needed: Update the CI, update dev environments and .csproj, use new apis available in .netcore3.0 and aspnetcore 3.0

So it simply boils down to the decision if we want to only support .netcore and not .net full framework moving forward?
cc: @msfussell @shalabhms @lukekim

Support CancellationToken in actor method calls with remoting. When CancellationToken is cancelled on the client side, the cnacellation token in remote method should be cancelled as well.

Run tools to scan for offensive terms in every context and triage the term if found and correct it.

Fix Dapr API specifications to point to docs reference

ESRP signing is broken because ESRP package is using dotnet core 2.0.

Change namespace, assembly & package to Dapr.* from Microsoft.Dapr.*

it is good to consider using open-telemetry in dotnet-sdk; open-telemetry for dot-net sdk - https://github.com/open-telemetry/opentelemetry-dotnet

Note: open-telemetry is new telemetry library which replaces open-census and open-tracing. open-census and open-tracing projects will be deprecated soon.

Change projecturl to https://github.com/dapr

With appropriate engineering review/gates/

I'm digging through #74 - and there's a bunch of non-trivial stuff that CloudEvents do.

It's going to be easy to do #74 because the scope is very limited - but for the longer term, have you had any conversations with the maintainers of that project? Someone who wants to process CloudEvents other than their payload will likely end up using it - I'm hoping we can make that a good experience - however I haven't had the time to go deep into it.

This might be something for @davidfowl and I to chase.

Add codegen to enable RPC like calls using ActorProxy to allow following strongly typed invocations:

// This only creates a proxy object, it does not activate an actor or invoke any methods yet.
IMyActor myActor = ActorProxy.Create<IMyActor>("ActorType")
// This will invoke a method on the actor. 
myActor.DoWorkAsync();

Now that we've got a gRPC client - do we want to take a more thorough look at the experience for ASP.NET Core + gRPC + Dapr? I happen to know a guy.

At this minimum this would probably be a review of some of the practices + more samples, at the maximum we might identify more features and integration points.

It'd be helpful to create a Dockerfile and detail how one goes about building the C# actor into a Docker image and then deploying it to Kubernetes with Dapr.

NonRemoting calls: Write exception from Actor method invocation in response body