magic.signals.contracts 14.0.0

.NET Standard 2.0
Install-Package magic.signals.contracts -Version 14.0.0
dotnet add package magic.signals.contracts --version 14.0.0
<PackageReference Include="magic.signals.contracts" Version="14.0.0" />
For projects that support PackageReference, copy this XML node into the project file to reference the package.
paket add magic.signals.contracts --version 14.0.0
The NuGet Team does not provide support for this client. Please contact its maintainers for support.
#r "nuget: magic.signals.contracts, 14.0.0"
#r directive can be used in F# Interactive, C# scripting and .NET Interactive. Copy this into the interactive tool or source code of the script to reference the package.
// Install magic.signals.contracts as a Cake Addin
#addin nuget:?package=magic.signals.contracts&version=14.0.0

// Install magic.signals.contracts as a Cake Tool
#tool nuget:?package=magic.signals.contracts&version=14.0.0
The NuGet Team does not provide support for this client. Please contact its maintainers for support.

A Super Signal implementation for Hyperlambda

magic.signals is a "Super Signals" implementation for .Net 6 built on top of magic.node, allowing you to invoke functions from one assembly in another assembly without having any direct references between your projects.


Below you can find a couple of articles written about the idea by yours truly.

The above is made possible by always having a YALOA, allowing us to invoke methods in classes through a "magic string", which references a type in a dictionary, where the string is its key, and the types are dynamically loaded during startup of your AppDomain. Imagine the following code.

[Slot(Name = "")]
public class FooBar : ISlot
    public void Signal(ISignaler signaler, Node input)
        input.Value = 42;

The above declares a "slot" for the signal []. In any other place in our AppDomain we can use an ISignaler instance to Signal the above slot by using something such as the following.

 * This will invoke our Signal method above
var args = new Node();
signaler.Signal("", args);

 * The value of args is now 42.
Assert.Equal(42, args.Value);

Notice that there are no shared types between the invoker and the handler, and there are no references necessary to be shared between these two assemblies. This results in an extremely loosely coupled plugin architecture, where you can dynamically add any plugin you wish into your AppDomain, by simply referencing whatever plugin assembly you wish to bring into your AppDomain, and immediately start consuming your plugin's functionality - Or dynamically loading it during runtime for that matter, resulting in that you instantly have access to its slots, without needing to create cross projects references in any ways.

This results in an extremely loosely coupled architecture of related components, where any one component can easily be exchanged with any other component, as long as it is obeying by the implicit interface of the component you're replacing. Completely eliminating "strongly typing", making interchanging components with other components equally simply in a static programming language such as the .Net CLR as providing a function object in JavaScript. In many ways, this results in having all the advantages from a functional programming language in a static programming language, while still keeping the strongly typing around for cases where you need strongly typing - Allowing you to choose which paradigm you want to use, based upon individual use cases, and not having the language and platform dictate your choices in these regards.

The magic.signals implementation uses IServiceProvider to instantiate your above FooBar class when it wants to evaluate your slot. This makes it behave as a good IoC citizen, allowing you to pass in for instance interfaces into your constructor, and have the .Net dependency injection automatically create objects of whatever interface your slot implementation requires.

There is also an async version of the interface, which allows you to declare async slots, transparently letting the runtime choose which implementation to use, depending upon whether or not it is currently in an async execution context or not. Below you can see how to accomplish the same as above, except this time the slot will be invoked within an async context.

[Slot(Name = "")]
public class FooBar : ISlotAsync
    public Task SignalAsync(ISignaler signaler, Node input)
        input.Value = 42;
        await Task.Yield();

It's a common practice to implements slots that recursively invokes other slots, by combining the above two constructs, into one single class. Below is an example.

[Slot(Name = "")]
public class FooBar : ISlot, ISlotAsync
    // Sync version.
    public void Signal(ISignaler signaler, Node input)
        input.Value = 42;

    // Async version.
    public Task SignalAsync(ISignaler signaler, Node input)
        input.Value = 42;
        await Task.Yield();

The above simple example is probably not that useful to implement as an async slot, but for other parts of your code, where you for instance are accessing sockets, HTTP connections, or the file system for that matter - Creating async slots will have huge advantages for your application's ability to scale, and handle multiple simultaneous users and connections. The runtime will "automagically" choose the correct implementation, being synchronous or asynchronous, depending upon which execution context the execution object currently is within.

If your slots recursively invokes other slots, by for instance invoking signaler.Signal("eval", args), you should also implement the async interface, to allow for children lambda objects to be within an async context. This has huge advantages for your application's throughput.

Passing arguments to your slots

The Node class provides a graph object for you, allowing you to automagically pass in any arguments you wish. Notice, the whole idea is to de-couple your assemblies, hence you shouldn't really pass in anything but "native types", such as for instance System.String, System.DateTime, integers, etc. However, most complex POD structures, can also easily be represented using this Node class. The Node class is basically a name/value/children graph object, where the value can be any object, the name a string, and children is a list of children Nodes. In such a way, it provides a more C# friendly graph object, kind of resembling JSON, allowing you to internally within your assemblies, pass in a Node object as your parameters from the point of your signal, to the slot where you handle the signal. The Node POCO class again, is a bi-directional POD instance, allowing you to both pass arguments into the slot, in addition to having the slot return values back to the caller.

If you invoke Signal or SignalAsync from C#, you can optionally pass in a function object that will be executed after the signal has been executed. This is useful for cases where you're creating an async signal invocation, but not invoking it immediately, and rather returning it as a Task to some other parts of your system, to ensure something occurs after the signal has been executed. Below is an example.

var args = new Node();
return signaler.SignalAsync("", args, () => { /* ... This will happen AFTER execution of signal ... */ });

Magic Signals a DSL

A lot of the idea behind Magic Signals is that combined with magic.node, and especially its ability to parse Hyperlambda, it becomes a very good foundation for a DSL, or a Domain Specific programming Language implementation, allowing you to easily create your own programming languages, and keywords, based upon Hyperlambda syntax trees. Hyperlambda in this context being the textual representation of your Node hierarchy.

Project website

The source code for this repository can be found at, and you can provide feedback, provide bug reports, etc at the same place.

Quality gates

  • Build status
  • Quality Gate Status
  • Bugs
  • Code Smells
  • Coverage
  • Duplicated Lines (%)
  • Lines of Code
  • Maintainability Rating
  • Reliability Rating
  • Security Rating
  • Technical Debt
  • Vulnerabilities
Product Versions
.NET net5.0 net5.0-windows net6.0 net6.0-android net6.0-ios net6.0-maccatalyst net6.0-macos net6.0-tvos net6.0-windows
.NET Core netcoreapp2.0 netcoreapp2.1 netcoreapp2.2 netcoreapp3.0 netcoreapp3.1
.NET Standard netstandard2.0 netstandard2.1
.NET Framework net461 net462 net463 net47 net471 net472 net48
MonoAndroid monoandroid
MonoMac monomac
MonoTouch monotouch
Tizen tizen40 tizen60
Xamarin.iOS xamarinios
Xamarin.Mac xamarinmac
Xamarin.TVOS xamarintvos
Xamarin.WatchOS xamarinwatchos
Compatible target framework(s)
Additional computed target framework(s)
Learn more about Target Frameworks and .NET Standard.

NuGet packages (29)

Showing the top 5 NuGet packages that depend on magic.signals.contracts:

Package Downloads

A generic and dynamic SQL data adapter, allowing you to generate SQL dialects, specific to your database type, such as MySQL or SQL Server. This is the core base class data adapter for Magic. To use package go to


A Super Signals implementation for Magic built on magic.node, allowing you to invoke functionality from one component in another component without any (direct) references between your components. To use package go to


Magic endpoint is a dynamic Hyperlambda endpoint evaluator, allowing you to create HTTP REST API endpoints dynamically, that will execute a Hyperlambda file when evaluated, where the URL is a reference to the physical path on disc to your Hyperlambda file. To use package go to

Service implementations for magic.endpoint, that allows you to dynamically evaluate Hyperlambda files associated with a URL. To use package go to


HTTP lambda helpers for Magic, allowing you to invoke HTTP REST endpoints using Magic and Hyperlambda. To use package go to

GitHub repositories

This package is not used by any popular GitHub repositories.

Version Downloads Last updated
14.0.0 1 6/25/2022
13.4.0 628 5/31/2022
13.3.4 583 5/9/2022
13.3.0 474 5/1/2022
13.2.0 675 4/21/2022
13.1.0 713 4/7/2022
13.0.0 523 4/5/2022
11.0.5 906 3/2/2022
11.0.4 624 2/22/2022
11.0.3 677 2/9/2022
11.0.2 699 2/6/2022
11.0.1 86 2/5/2022
11.0.0 652 2/5/2022
10.0.21 869 1/28/2022
10.0.20 643 1/27/2022
10.0.19 585 1/23/2022
10.0.18 573 1/17/2022
10.0.15 1,177 12/31/2021
10.0.14 898 12/28/2021
10.0.7 1,549 12/22/2021
10.0.5 1,103 12/18/2021
9.9.9 1,436 11/29/2021
9.9.3 1,894 11/9/2021
9.9.2 1,665 11/4/2021
9.9.0 2,108 10/30/2021
9.8.9 1,920 10/29/2021
9.8.7 1,885 10/27/2021
9.8.6 1,937 10/27/2021
9.8.5 1,951 10/26/2021
9.8.0 2,796 10/20/2021
9.7.9 2,096 10/19/2021
9.7.5 2,984 10/14/2021
9.7.0 2,103 10/9/2021
9.6.6 681 8/14/2021
9.2.0 10,313 5/26/2021
9.1.4 5,938 4/21/2021
9.1.0 2,177 4/14/2021
9.0.0 2,198 4/5/2021
8.9.9 7,210 3/30/2021
8.9.3 2,677 3/19/2021
8.9.2 1,929 1/29/2021
8.9.1 2,025 1/24/2021
8.9.0 2,692 1/22/2021
8.6.9 3,887 11/8/2020
8.6.6 2,787 11/2/2020
8.6.0 4,105 10/28/2020
8.5.0 2,718 10/23/2020
8.4.0 5,652 10/13/2020
8.3.1 3,139 10/5/2020
8.3.0 2,239 10/3/2020
8.2.2 2,830 9/26/2020
8.2.1 2,264 9/25/2020
8.2.0 2,142 9/25/2020
8.1.17 6,748 9/13/2020
8.1.16 478 9/13/2020
8.1.15 3,967 9/12/2020
8.1.11 3,319 9/11/2020
8.1.10 2,507 9/6/2020
8.1.9 2,853 9/3/2020
8.1.8 2,533 9/2/2020
8.1.7 2,003 8/28/2020
8.1.4 2,031 8/25/2020
8.1.3 2,081 8/18/2020
8.1.2 2,030 8/16/2020
8.1.1 2,154 8/15/2020
8.1.0 360 8/15/2020
8.0.1 4,330 8/7/2020
8.0.0 2,086 8/7/2020
7.0.1 293 8/7/2020
7.0.0 3,829 6/28/2020
5.0.0 7,096 2/25/2020
4.0.4 7,024 1/27/2020
4.0.3 2,208 1/27/2020
4.0.2 2,411 1/16/2020
4.0.1 2,300 1/11/2020
4.0.0 2,293 1/5/2020
3.1.0 5,852 11/10/2019
3.0.0 7,525 10/23/2019
2.0.1 7,735 10/15/2019
2.0.0 2,694 10/13/2019
1.1.9 2,117 10/11/2019
1.1.8 2,781 10/10/2019
1.1.7 2,430 10/9/2019
1.1.6 864 10/7/2019
1.1.5 2,378 10/6/2019
1.1.3 1,967 10/6/2019
1.1.2 1,735 10/5/2019
1.0.1 1,285 9/26/2019
1.0.0 639 9/26/2019