DEV Community: Dmitry

WitCom and Discovery

Dmitry — Mon, 03 Mar 2025 15:04:46 +0000

As discussed in previous articles, WitCom is inspired by WCF—not necessarily in its internal implementation, but in terms of developer experience and capabilities. One of the key technologies that WCF offered “out of the box” was Discovery. With Discovery, a server could announce its presence on a local network via UDP multicast, allowing clients to learn about available services and decide whether to connect. WitCom offers a similar feature, enhancing flexibility in dynamic environments.

Server-Side Discovery

To enable Discovery during server creation, simply include the appropriate option when building your WitCom server. For example:

var server = WitComServerBuilder.Build(options =>
{
    options.WithService(ExampleService);
    options.WithNamedPipe(address);
    options.WithEncryption();
    options.WithJson();
    options.WithDiscovery();
    options.WithAccessToken(ACCESS_TOKEN);
    options.WithTimeout(TimeSpan.FromSeconds(1));
    options.WithName(dialog.ServerName);
    options.WithDescription(dialog.ServerDescription);
});

By default, if you do not specify custom parameters, a one-time “Hello” message is sent at server startup and a “Goodbye” message when it shuts down. These messages are broadcast to the standard multicast address 239.255.255.250 and port 3702.

You can also customize the Discovery parameters:

Custom Address and Port

options.WithDiscovery(host, port);

Periodic Announcements

To continuously remind clients that the server is still available, you can specify a repeat interval:

options.WithDiscovery(host, port, TimeSpan.FromSeconds(10));

or simply:

options.WithDiscovery(TimeSpan.FromSeconds(10));

In this case, while the server is running and accepting connections, a Discovery message is sent every 10 seconds.

The Discovery message contains critical information such as:

The transport type and connection settings (for example, the name of the memory-mapped file, the named pipe, the TCP port, or the WebSocket URL).
The server’s name and description (if provided during initialization).

Client-Side Discovery

On the client side, to receive Discovery messages, you need to create a Discovery client. For instance:

DiscoveryClient = WitComClientBuilder.Discovery(options =>
{
    options.WithLogger(Logger);
    options.WithJson();
    options.WithAddress(host, port);
});

Note: Ensure that you specify the same serializer as on the server (JSON is used by default). If no address is provided, the default multicast address (239.255.255.250) and port (3702) are used.

Next, subscribe to the event that is fired upon receiving a Discovery message:

DiscoveryClient.MessageReceived += OnMessageReceived;

Then start listening:

DiscoveryClient.Start();

Once a Discovery message is received, you can build a WitCom client by selecting the appropriate transport based on the content of the message. For example:

var client = WitComClientBuilder.Build(options =>
{
    options.WithTransport(SelectedMessage);
    options.WithEncryption();
    options.WithJson();
    options.WithAccessToken(ACCESS_TOKEN);
    options.WithLogger(Logger);
    options.WithTimeout(TimeSpan.FromSeconds(1));
});

Here’s an example helper method that configures the transport according to the Discovery message:

public static WitComClientBuilderOptions WithTransport(this WitComClientBuilderOptions me, DiscoveryMessage message)
{
    if (message.Data == null)
        throw new ArgumentOutOfRangeException(nameof(me), me, null);

    if (message.IsMemoryMappedFile())
        return me.WithMemoryMappedFile(message);

    if (message.IsNamedPipe())
        return me.WithNamedPipe(message);

    if (message.IsTcp())
        return me.WithTcp("localhost", message);

    if (message.IsWebSocket())
        return me.WithWebSocket("ws://localhost", message);

    throw new ArgumentOutOfRangeException(nameof(me), me, null);
}

Examples and Further Resources

You can find detailed examples of using Discovery with WitCom on GitHub: WitCom Discovery Examples

References and Resources

For more in-depth information on WitCom, please refer to the following resources:

WitCom Overview
WitCom and Blazor WebAssembly
WitCom and Static Proxy
Inter-process Communication with WitCom
WitCom Project Root

Inter-process Communication with WitCom

Dmitry — Mon, 13 Jan 2025 10:47:45 +0000

Working on engineering systems that often involve legacy components, I frequently face challenges in integrating outdated elements with modern platforms. For example, you may encounter scenarios requiring support for obsolete file formats that can only be opened by a 32-bit component. This limitation poses a dilemma: either remain on an outdated platform, foregoing modern framework advantages like 64-bit addressing, or isolate the legacy component’s logic into a separate process with which the main application communicates.

There are numerous scenarios for inter-process communication (IPC) on the same machine, including:

Supporting components built for a different platform than the main system.
Running multiple parallel, independent processes to overcome system limitations.
Enabling data exchange between several concurrently running applications. Many others.

Why WitCom?

For years, I relied on WCF for its flexibility, particularly its support for selecting optimized transports like named pipes for local interactions. However, WCF was no longer fully available when I migrated to .NET Core. While recent .NET versions have reintroduced support for WCF, its current status remains uncertain.

One of WCF’s standout features was ServiceContract, which allows defining a service interface. This approach simplifies development: a client integrating a WCF service generates the required wrapper code automatically, eliminating guesswork about function names or parameters. Unfortunately, both SignalR and gRPC require method calls using plain text method names, complicating code maintenance.

Enter WitCom

A few years ago, I discovered the IpcServiceFramework, which uses interfaces to define services and leverages reflection to unpack and invoke methods on the service side. While promising, the project was no longer maintained. Inspired by its core concept, I developed my own implementation, which evolved into WitCom.

WitCom is a WCF-like communication framework designed for .NET. It enables developers to define service interfaces, choose a transport, and establish full-duplex communication with minimal effort. Supported transports include common options like Named Pipes, TCP, and WebSocket, as well as unique support for memory-mapped files. This enables ultra-fast, low-latency duplex communication on a local machine, ideal for transferring large volumes of data with maximum efficiency.

Example: Inter-process Communication with WitCom

You can find an example implementation in the WitCom GitHub repository.

Step 1: Define the Service Contract

public interface IExampleService
{
    event ExampleServiceEventHandler ProcessingStarted;
    event ExampleServiceProgressEventHandler ProgressChanged;
    event ExampleServiceProcessingEventHandler ProcessingCompleted;

    bool StartProcessing();
    void StopProcessing();
}

public delegate void ExampleServiceEventHandler();
public delegate void ExampleServiceProgressEventHandler(double progress);
public delegate void ExampleServiceProcessingEventHandler(ProcessingStatus status);

WitCom supports full-duplex communication natively using event callbacks, with any delegate type (e.g., PropertyChangedEventHandler) supported.

Step 2: Implement the Service in the Agent

The agent process hosts the service:

public class ExampleService : IExampleService
{
    public event ExampleServiceEventHandler ProcessingStarted = delegate { };
    public event ExampleServiceProgressEventHandler ProgressChanged = delegate { };
    public event ExampleServiceProcessingEventHandler ProcessingCompleted = delegate { };

    private CancellationTokenSource? CancellationTokenSource { get; set; }

    public bool StartProcessing()
    {
        if (CancellationTokenSource != null) return false;

        CancellationTokenSource = new CancellationTokenSource();
        Task.Run(Process);

        ProcessingStarted();
        return true;
    }

    public void StopProcessing()
    {
        CancellationTokenSource?.Cancel();
    }

    private void Process()
    {
        ProcessingStatus status = ProcessingStatus.Success;
        for (int i = 1; i <= 100; i++)
        {
            if (CancellationTokenSource?.IsCancellationRequested == true)
            {
                status = ProcessingStatus.Interrupted;
                break;
            }
            ProgressChanged(i);
            Thread.Sleep(100);
        }

        ProcessingCompleted(status);
        CancellationTokenSource = null;
    }
}

Step 3: Start the Agent Process

The host process launches the agent as a separate process, passing the communication address via command-line arguments. For example:

var process = new Process
{
    StartInfo = new ProcessStartInfo
    {
        FileName = "Agent.exe",
        Arguments = "--address=ExampleMemoryMap",
        UseShellExecute = false,
    }
};
process.Start();

Step 4: Start the Server in the Agent

The agent starts the server and listens for connections using the received address:

var server = WitComServerBuilder.Build(options =>
{
    options.WithService(new ExampleService());
    options.WithMemoryMappedFile("ExampleMemoryMap");
    options.WithEncryption();
    options.WithJson();
    options.WithAccessToken("SecureAccessToken");
    options.WithTimeout(TimeSpan.FromSeconds(1));
});
server.StartWaitingForConnection();

Step 5: Create the Client in the Host

The host process connects to the agent:

var client = WitComClientBuilder.Build(options =>
{
    options.WithMemoryMappedFile("ExampleMemoryMap");
    options.WithEncryption();
    options.WithJson();
    options.WithAccessToken("SecureAccessToken");
    options.WithTimeout(TimeSpan.FromSeconds(1));
});

if (!await client.ConnectAsync(TimeSpan.FromSeconds(5), CancellationToken.None))
{
    Console.WriteLine("Failed to connect.");
    return;
}

var service = client.GetService<IExampleService>();
service.ProcessingStarted += () => Console.WriteLine("Processing started!");
service.ProgressChanged += progress => Console.WriteLine($"Progress: {progress}%");
service.ProcessingCompleted += status => Console.WriteLine($"Processing completed: {status}");

Key Advantages of WitCom

Service Contracts: Define service interfaces for a clean and maintainable API.
Multiple Transports: Choose from Named Pipes, TCP, WebSocket, or memory-mapped files.
Full-Duplex Communication: Events and callbacks are natively supported.
Encryption: Secure communication with AES/RSA-based encryption.
Authorization: Token-based authentication ensures only authorized clients can connect.
High Performance: Optimize IPC for the local machine using memory-mapped files.
Easy Error Handling: Use WitComExceptionFault to handle communication errors.

Conclusion

WitCom is a robust and modern alternative for inter-process communication in .NET, combining the best features of WCF with modern transport options. For more information, visit WitCom’s documentation and explore examples on GitHub.

WitCom: Modernizing Client-Server Communication

Dmitry — Mon, 06 Jan 2025 10:45:42 +0000

WitCom is a versatile and innovative API designed to simplify client-server communication, offering intuitive interfaces, robust security, and flexible serialization options. With support for multiple transport mechanisms, including WebSocket, TCP, REST, and even Memory-mapped files, it caters to diverse application needs. Its event-driven architecture and customizable components make it an ideal choice for small-scale projects or complex distributed systems where both client and server are implemented with .Net, positioning WitCom as a modern and simple-to-use alternative to WCF and SignalR.

Key Features of WitCom

Simplicity and Native Use: WitCom’s design ensures intuitive implementation. By eliminating the reliance on text-based messaging, lambda functions, or complex expressions, it simplifies the development process, especially for developers transitioning from other frameworks. Its native approach means developers work with familiar tools and paradigms, reducing the learning curve.
Duplex Communication: WitCom excels in enabling full duplex communication, allowing seamless two-way message exchanges between client and server. Built-in event and callback support accommodates a wide array of delegate types, such as PropertyChangedEventHandler. This duplex model is ideal for applications requiring constant interaction, like live updates, synchronized data sharing, or collaborative systems.
Client-Side Proxy Mirrors Server: A defining feature of WitCom is its ability to create a dynamic proxy on the client side that mirrors the interface of the server object. This means that by simply invoking methods or accessing properties on the client’s proxy, you directly interact with the server. Additionally, subscribing to events on the proxy seamlessly triggers server-side events, making the entire client-server communication invisible and effortless for the user. Developers work naturally with the interface, while WitCom handles all underlying communication.
Interface-Driven Architecture: Service interfaces in WitCom are defined using standard .NET interfaces. This promotes strong type safety and allows for the auto-generation of dynamic client-side proxies that act as exact replicas of server-side services, ensuring consistent behavior across the application.
Transport Versatility: WitCom supports a variety of transport mechanisms, making it adaptable to a range of scenarios and infrastructures:
- Memory-Mapped Files: Designed for ultra-fast inter-process communication (IPC) on a single machine.
- Named Pipes: Effective for IPC within the same network or machine, supporting multiple clients.
- TCP: Provides robust and reliable communication for distributed systems, making it suitable for large-scale applications.
- WebSocket: Enables efficient, real-time bidirectional communication across web platforms.
- REST: Simplifies interaction with non-.NET clients, providing rapid deployment of RESTful APIs for external integrations.
Extensive Customization:
- Full support for generic functions and properties.
- Flexible serialization formats, including JSON and MessagePack.
- Optional security features, such as end-to-end encryption and token-based authorization.
- Developers can override default implementations for highly specific requirements, ensuring the API adapts to unique project demands.

Enhanced Security: Encryption and Authorization

Security lies at the heart of WitCom’s design, providing robust mechanisms for both encryption and authorization. These capabilities are built on flexible, extensible interfaces, with default implementations included for most standard use cases.

End-to-End Encryption: WitCom’s encryption framework ensures secure communication between clients and servers. By default, AES (Advanced Encryption Standard) handles symmetric encryption, while RSA facilitates secure key exchange. This layered security provides:
- Data Confidentiality: Ensures that transmitted data is encrypted and inaccessible to unauthorized entities.
- Integrity: Validates the integrity of the data, preventing tampering during transit.

Developers can implement custom encryption logic by adhering to IEncryptorServerand IEncryptorClient interfaces, allowing tailored security measures where required.

Example configuration for enabling encryption:

var server = WitComServerBuilder.Build(options =>
{
    options.WithEncryption();
});

var client = WitComClientBuilder.Build(options =>
{
    options.WithEncryption();
});

Token-Based Authorization: Authorization is seamlessly integrated through token-based systems, providing an additional layer of security. By default, WitCom includes static token validators suitable for most scenarios. Developers can extend functionality by implementing IAccessTokenValidatorfor customized authorization logic, allowing for integration with advanced identity management systems.

Example:

public class AccessTokenValidator : IAccessTokenValidator
{
    private readonly string _validToken;

    public AccessTokenValidator(string validToken)
    {
        _validToken = validToken;
    }

    public bool IsAuthorizationTokenValid(string token)
    {
        return token == _validToken;
    }
}

var server = WitComServerBuilder.Build(options =>
{
    options.WithAccessTokenValidator(new AccessTokenValidator("secure-token"));
});

Serialization Options: JSON and MessagePack

Serialization in WitCom is both flexible and efficient, catering to a variety of application needs. Default implementations of serializers are provided, but developers are free to customize by implementing the IMessageSerializerinterface.

JSON Serialization: JSON is the default format, offering unparalleled readability and widespread support across platforms. Its human-readable format is particularly advantageous during debugging and integration with third-party systems.

Example configuration:

var server = WitComServerBuilder.Build(options =>
{
    options.WithJson();
});

var client = WitComClientBuilder.Build(options =>
{
    options.WithJson();
});

MessagePack Serialization: For high-performance applications, MessagePack offers a compact binary serialization format that significantly reduces payload size. This is ideal for bandwidth-sensitive environments or systems with stringent performance requirements.

Example configuration:

var server = WitComServerBuilder.Build(options =>
{
    options.WithMessagePack();
});

var client = WitComClientBuilder.Build(options =>
{
    options.WithMessagePack();
});

Setting Up WitCom

To illustrate the simplicity of WitCom, consider the following example for setting up a basic service:

Define the Service Interface:

public interface IExampleService
{
    event ExampleServiceEventHandler ProcessingStarted;
    event ExampleServiceProgressEventHandler ProgressChanged;
    event ExampleServiceProcessingEventHandler ProcessingCompleted;

    bool StartProcessing();
    void StopProcessing();
}

public delegate void ExampleServiceEventHandler();
public delegate void ExampleServiceProgressEventHandler(double progress);
public delegate void ExampleServiceProcessingEventHandler(ProcessingStatus status);

Implement the Service:

public class ExampleService : IExampleService
{
    public event ExampleServiceEventHandler ProcessingStarted = delegate { };
    public event ExampleServiceProgressEventHandler ProgressChanged = delegate { };
    public event ExampleServiceProcessingEventHandler ProcessingCompleted = delegate { };

    private CancellationTokenSource? _cancellationTokenSource;

    public bool StartProcessing()
    {
        if (_cancellationTokenSource != null) return false;
        _cancellationTokenSource = new CancellationTokenSource();
        Task.Run(Process);
        ProcessingStarted();
        return true;
    }

    public void StopProcessing()
    {
        _cancellationTokenSource?.Cancel();
    }

    private void Process()
    {
        for (int i = 1; i <= 100; i++)
        {
            if (_cancellationTokenSource?.IsCancellationRequested == true)
            {
                ProcessingCompleted(ProcessingStatus.Interrupted);
                return;
            }
            ProgressChanged(i);
            Thread.Sleep(100);
        }
        ProcessingCompleted(ProcessingStatus.Success);
    }
}

Configure the Server:

var server = WitComServerBuilder.Build(options =>
{
    options.WithService(new ExampleService());
    options.WithWebSocket("http://localhost:5000", 10);
    options.WithJson();
    options.WithEncryption();
});

server.StartWaitingForConnection();

Connect the Client:

var client = WitComClientBuilder.Build(options =>
{
    options.WithWebSocket("ws://localhost:5000");
    options.WithJson();
    options.WithEncryption();
});

await client.ConnectAsync(TimeSpan.FromSeconds(5), CancellationToken.None);
var service = client.GetService<IExampleService>();

service.ProcessingStarted += () => Console.WriteLine("Processing Started");
service.ProgressChanged += progress => Console.WriteLine($"Progress: {progress}%");
service.ProcessingCompleted += status => Console.WriteLine($"Processing Completed: {status}");

service.StartProcessing();

Examples and GitHub Repository

Explore the complete source code and examples for WitCom:

GitHub Repository: WitCom
Inter-Process Communication Examples: Examples/InterProcess
Multi-Client Service Examples: Examples/Services

WitCom Advantages

Ease of Use: WitCom eliminates boilerplate code, offering an intuitive setup experience.
Event-Driven Model: Its event-centric design makes it ideal for reactive and real-time applications.
Performance: Features like memory-mapped files optimize performance for local IPC scenarios.
Flexibility: Extensive transport and serialization options cater to diverse use cases.

WitCom empowers developers with a robust yet simple framework for modern client-server communication. By combining powerful features, high performance, and flexibility, it meets the demands of both small-scale and enterprise-level systems. Whether building responsive applications or managing large-scale distributed systems, WitCom represents a significant step forward in .NET communication frameworks.

Streamlining .NET Development with Practical Aspects

Dmitry — Wed, 20 Nov 2024 14:51:27 +0000

Aspect-oriented programming (AOP) provides a robust approach to encapsulate cross-cutting concerns into reusable components called aspects. By separating these concerns from business logic, AOP helps streamline development, reduce boilerplate code, and enhance maintainability. In this article, I’ll explore three practical aspects that I am using for almost all my projects: Notify, Log, and Bindable, demonstrating how they simplify common programming tasks and improve code quality.

All examples are implemented using the Aspect Injector, but the same logic can be adapted to other AOP frameworks. This approach is not tied to any specific library and can be easily customized to fit your project’s needs.

Automating Property Change Notifications with the Notify Aspect

When working with the MVVM pattern (and not only), there’s a frequent need to track changes in properties.
To achieve this, the model class for which we want to track property changes must implement the INotifyPropertyChanged interface. Each property then has to explicitly invoke the PropertyChangedEventHandler when modified:

public class Model : INotifyPropertyChanged
{
    public event PropertyChangedEventHandler? PropertyChanged = delegate { };

    private string m_text;

    public string Text
    {
        get
        {
            return m_text;
        }
        set
        {
            m_text = value;
            PropertyChanged(this, new PropertyChangedEventArgs(nameof(Text)));
        }
    }
}

This approach bloats the code and requires inserting repetitive constructs. Even when simplified, such as avoiding plain text arguments, it still results in verbose code, increasing the chance of missing something or introducing errors.

This problem is perfectly solved using aspects. Fortunately, the Aspect Injector framework provides a built-in Notify aspect for automating property change notifications. With this, the above code can be rewritten as follows:

public class Model
{
    [Notify]
    public string Text { get; set; }
}

The aspect will automatically generate a PropertyChangedEventHandler and invoke it on behalf of the class. This works seamlessly with WPF UI.

But what if we want to monitor property changes for custom purposes? For example, we might need to attach to the PropertyChanged event and execute additional logic when properties change. Unfortunately, relying solely on the Notify aspect provided by Aspect Injector won’t work as expected:

public class Model : INotifyPropertyChanged
{
    public event PropertyChangedEventHandler? PropertyChanged = delegate { };

    public Model()
    {
        this.PropertyChanged += OnPropertyChanged;
    }

    private void OnPropertyChanged(object? sender, PropertyChangedEventArgs e)
    {
        if (e.PropertyName == nameof(Text))
        {
            // This block will never be executed...
        }
    }

    [Notify]
    public string Text { get; set; }
}

To enable this, we need to modify the implementation of the aspect. Specifically, the aspect should detect whether the class implements INotifyPropertyChanged and invoke the internal event. This can be achieved using the power of reflection:

public static bool FirePropertyChanged(string propertyName, INotifyPropertyChanged obj)
{
    var eventDelegate = GetPropertyChangedField(obj.GetType())?.GetValue(obj) as MulticastDelegate;
    if (eventDelegate == null)
        return false;

    var delegates = eventDelegate.GetInvocationList();
    foreach (var dlg in delegates)
        try
        {
            dlg.Method.Invoke(dlg.Target, new object[] { obj, new PropertyChangedEventArgs(propertyName) });
        }
        catch (TargetInvocationException targetInvocationException)
        {
            if (targetInvocationException.InnerException != null)
                throw targetInvocationException.InnerException;
        }

    return true;
}

private static FieldInfo? GetPropertyChangedField(Type objType)
{
    while (true)
    {
        var property = objType.GetFields(BindingFlags.Instance | BindingFlags.NonPublic)
                              .SingleOrDefault(x => x.FieldType == typeof(PropertyChangedEventHandler));
        if (property != null)
            return property;

        if (objType.BaseType?.GetInterface(nameof(INotifyPropertyChanged)) == null)
            return null;

        objType = objType.BaseType;
    }
}

A detailed implementation of this aspect can be found in the OutWit repository on GitHub.

To use this extended functionality, you need to install the OutWit.Common.Aspects NuGet package and utilize the Notify aspect from it. With this modification, the code will behave as expected:

public class Model : INotifyPropertyChanged
{
    public event PropertyChangedEventHandler? PropertyChanged = delegate { };

    public Model()
    {
        this.PropertyChanged += OnPropertyChanged;
    }

    private void OnPropertyChanged(object? sender, PropertyChangedEventArgs e)
    {
        if (e.PropertyName == nameof(Text))
        {
            Trace.Write("I am here!");
        }
    }

    [Notify]
    public string Text { get; set; }
}

This extended Notify aspect ensures both WPF compatibility and the ability to react to property changes for custom purposes, making it a robust solution for property change tracking.

Streamlining Logging with the Log Aspect

Maintaining logs is an essential practice for any sufficiently complex application, as it greatly simplifies debugging and support. Logs help developers understand the sequence of events or user actions that led to a specific result.

For larger projects, explicitly calling logging methods every time they’re needed can be tedious and error-prone. The OutWit.Common.Logging package provides a powerful set of logging aspects that can automate much of this process.
The source code for these aspects is available here.

This implementation is based on Serilog but can be easily adapted to other logging frameworks. Before using these aspects, you must initialize the logger:

Log.Logger = new LoggerConfiguration()
.MinimumLevel.Is(LogEventLevel.Information)
.Enrich.WithExceptionDetails()
.WriteTo.File(@"D:\Log\Log.txt",
    rollingInterval: RollingInterval.Day,
    rollOnFileSizeLimit: true,
    fileSizeLimitBytes: 524288)
.CreateLogger();

Once initialized, the following three aspects become available:

Log Aspect

The Log aspect can be applied to individual methods:

public class Model
{
    [Log]
    public void DoSomething1()
    {
    }

    public void DoSomething2()
    {
    }
}

Or to an entire class:

[Log]
public class Model
{
    public void DoSomething1()
    {
    }

    public void DoSomething2()
    {
    }
}

When applied to a class, the Log aspect is effectively applied to all methods within the class.

What does this aspect do?

Exception Handling:
The Log aspect wraps method execution in a try-catch block. If an exception is thrown, it logs the exception details, including its parameters.
Method Execution Logging:
If the logger’s MinimumLevel is set to Information or lower, the aspect logs each method call (excluding property getters and setters).
Detailed Property Access Logging:
When the logger’s MinimumLevel is set to Verbose, the aspect also logs access to properties.

This allows you to control the level of detail in your logs by simply adjusting the logger’s configuration.

NoLog Aspect

If the Log aspect is applied to an entire class, but you need to exclude specific methods from logging (e.g., frequently called methods that could clutter the logs), the NoLog aspect can be used:

[Log]
public class Model
{
    public void DoSomething1()
    {
    }

    [NoLog]
    public void DoSomething2()
    {
    }
}

The NoLog aspect disables logging for the specified method, even if the Log aspect is applied at the class level.

Measure Aspect

Sometimes, the primary goal is to measure how long an operation takes to execute. Applying the Measure aspect to a method will log its execution time in milliseconds:

public class Model
{
    public void DoSomething1()
    {
    }

    [Measure]
    public void DoSomething2()
    {
    }
}

When DoSomething2 is called, the log will include a message indicating how long the method took to execute.

These aspects not only simplify logging but also ensure consistency across your application. Whether you need basic logging, selective exclusions, or precise performance measurements, these tools provide a flexible and powerful solution for your .NET applications.

Simplifying DependencyProperty Management with the Bindable Aspect

When working with WPF, dealing with DependencyProperty is a frequent and often tedious task. Declaring a DependencyProperty correctly is even more cumbersome than handling INotifyPropertyChanged.

For every DependencyProperty, you typically need to:

Declare the static DependencyProperty:

public static readonly DependencyProperty ValueProperty =
DependencyProperty.Register("Value", typeof(int), typeof(MyControl),
    new PropertyMetadata(0, new PropertyChangedCallback(OnValueChanged)));

Create a local property to access the value:

public int Value
{
    get => (int)GetValue(ValueProperty);
    set => SetValue(ValueProperty, value);
}

This process is verbose and error-prone, with multiple places where mistakes can be introduced or something might be forgotten.

To simplify this workflow, the OutWit.Common.MVVM package provides a set of tools, including the Bindable aspect. The source code is available here.

Making DependencyProperty Registration Cleaner

The BindingUtils utility included in the package simplifies the declaration of DependencyProperty by offering a more concise syntax:

public static readonly DependencyProperty ValueProperty =
BindingUtils.Register<MyControl, int>(nameof(Value), OnValueChanged);

This makes the DependencyProperty registration cleaner and less error-prone, improving code readability.

Eliminating GetValue and SetValue with Bindable Aspect

The Bindable aspect takes simplification even further by eliminating the need for explicit GetValue and SetValue calls in your property definition. Here’s how it looks in action:

[Bindable]
public int Value { get; set; }

With the Bindable aspect, the boilerplate code is reduced, resulting in cleaner and more maintainable classes.

Default Behavior and Custom Names

By default, the aspect assumes that the DependencyProperty corresponding to a property named [Name] is declared as [Name]Property. For example, for the property Value, the aspect expects the DependencyProperty to be named ValueProperty.

If your DependencyProperty uses a different name, you can specify it explicitly as a parameter to the attribute:

[Bindable("CustomDependencyProperty")]
public int Value { get; set; }

This allows flexibility while still maintaining a concise and readable property definition.

The Bindable aspect, combined with BindingUtils, significantly reduces the amount of repetitive code required when working with DependencyProperty. It ensures consistency and improves readability, helping developers focus more on the logic of their application rather than boilerplate code.

Conclusion

Aspects are a powerful tool to simplify repetitive and error-prone coding tasks, allowing developers to focus on the core logic of their applications. Here, I explored three practical aspects—Notify, Log, and Bindable—and demonstrated how they can streamline property change notifications, logging, and DependencyProperty management in .NET development.

All examples presented here leverage the following packages:

OutWit.Common.Aspects: Source Code
OutWit.Common.Logging: Source Code
OutWit.Common.MVVM: Source Code

By incorporating these tools into your projects, you can reduce boilerplate code, improve maintainability, and make your codebase cleaner and more efficient.