* Add support for JSInvokable methods on generic types
Prior to this change, DotNetDispatcher cached the MethodInfo on the
generic type definition. Using this would have required MethodInfo.MakeGenericMethod before the method was invoked.
We could separately cache the result of this to avoid the reflection cost per invocation.
Alternatively we could cache static and non-static MethodInfo instances separately which is what this change attempts to do.
The big difference in the outcome is that this requires instance (non-static) JSInvokable methods to be only unique named within
the type hierarchy as opposed to across all static and instance JSInvokable methods in an assembly.
Fixes https://github.com/aspnet/Extensions/issues/1360
Fixes https://github.com/aspnet/AspNetCore/issues/9061
\n\nCommit migrated from 659b604fb2
* Remove the use of async local JSRuntime
* Update DotNetDispatcher to accept a JSRuntime instance rather than use a ambient value.
* Modify DotNetObjectReference to start tracking it's value during serialization.
\n\nCommit migrated from ae9878bb99
* Special case Disposing DotNetObjectReferences
This removes a public JSInvokable method required for disposing DotNetObjectReferences
\n\nCommit migrated from d6bfc28e21
* Add an overload to handle .NET completion calls without going through JS interop.
* Add endInvokeHook on the client-side.
* Replace OnDotNetInvocationException with EndInvokeDotNet.\n\nCommit migrated from 4312b9a050
* Handle non existing dotnet object references and returns the error through JSInterop instead of bubbling it up to the caller.
* Every other error in JSInterop is returned that way.
* It makes sure that the error gets to the client and is sanitized appropriately if necessary.\n\nCommit migrated from a30f2cbb27
* Adds the ability to configure a default timeout for JavaScript interop calls.
* Adds the ability to pass in a cancellation token to InvokeAsync that will be used instead of the default timeout.
* A default cancellation token can be passed to signal no cancellation, but it is not recommended in remote interop scenarios.\n\nCommit migrated from e04faac7e4
Adds the ability to sanitize exceptions during JS to .NET interop calls by overriding OnDotNetInvocationException method and returning an object to be returned to JavaScript that describes the exception.\n\nCommit migrated from d7eab7c083
* Use Arcade's convention for setting IsPackable (must be explicitly set)
* Use Arcade conventions for using DebugType and eng/Versions.props
* Remove dead code
* Update restore feeds in daily builds.md
* Disable UsingToolNetFrameworkReferenceAssemblies in analyzer tests
* Remove usage of TestGroupName (an obsolete KoreBuild setting)
* Use IVT as a .csproj attribute
\n\nCommit migrated from f12d709976
The fix for this is to use more ExceptionDispatchInfo! Basically
everwhere that we handle an exception is now an EDI. It's easy to pass
these around and they do the right thing as far as perserving the stack
in.
I de-factored this code a little bit to make all of this work, but it's
now pretty unambiguously correct upon inspection.
I started out wanting to get rid of the continue-with because we've
found that pretty error prone overall. However making this method
async-void started to ask more questions than it answered. What happens
if serialization of the exception fails?
\n\nCommit migrated from 0a27fd3ad6
* Remove obsolete targets, properties, and scripts
* Replace IsProductComponent with IsShipping
* Undo bad merge to version.props
* Update documentation, and put workarounds into a common file
* Replace usages of RepositoryRoot with RepoRoot
* Remove API baselines
* Remove unnecessary restore feeds and split workarounds into two files
* Enable PR checks on all branches, and disable autocancel\n\nCommit migrated from f41cfded3c