SheepAspect Preview 2!

I’m very excited to announce the second preview release of SheepAspect. It’s available now, and you can install it to your project from NuGet gallery.

There are few new features introduced on this release, such as changes around its API, introducing more simplicity, bug fixes, and improved implementations. But there are few things that I’d like to highlight what’s new in this release.

NuGet Package

Previously, installing SheepAspect has always been a bit of a mess. You had to reference few libraries into your project, copy some compiler.exe into a folder, modify your csproj manually to include the compiler into your build-task, and pray all the stars are lined up in a perfect angle.

Now in Preview-2, NuGet will do all the mundane heavy-lifting for you. The only step you need to do now is to NuGet SheepAspect straight to your main project, and that’s it. Everything will be configured for you, and you’ll be all set to go before you finish reading this sentence.

When you NuGet SheepAspect into your project, there are 4 things that happen:

  1. It downloads all binaries and compiler into your project, and attach the necessary runtime libraries into your project references.
  2. It modifies your .csproj/.vbproj file to hook SheepAspect compiler into your post-build task.
  3. Generates a default configuration file (SheepAspect.config) and add to your project. This file has been pre-configured to just work immediately, which you can then use as a starting point to configure your SheepAspect settings. (More about this below).
  4. You’ll also be given one sample aspect class (/Aspects/SampleAspect.cs), and all it does is trace-logging around all public methods within your current project. (Entry, exit, exceptions).

The included sample-aspect is readily active and all fully functioning out-of-the-box, so that as soon as you nuget SheepAspect into your project and hit run immediately, you’ll watch all your public methods are now writing log traces to your debug window. From here, you can use this sample ‘SampleAspect.cs’ as a template to get started to write your very own first aspects.


Another new feature introduced in Preview-2 is an easier configurability. So instead of tinkering with your .csproj/.vbproj msbuild tasks to configure SheepAspect compilation settings, you can now do so in SheepAspect.config. When you install SheepAspect, you’ll get a default config:

<?xml version="1.0" encoding="utf-8" ?>
<sheepaspect-config xmlns="urn:sheepaspect-config-1.0">

It’s pretty straightforward. The xsd file is included so you can use Visual Studio intellisense to view all the different settings, although it’s all pretty basic at this point.

Build Report

SheepAspect compiler task spawns a separate (console) process to get around Visual Studio annoying tendency to lock dll files that you access during the task. That’s why in Preview-1 you could briefly see a console window popping up during compilation process. When an error occurs during the compilation, you’ll need to read the report printed on the console window.

The new SheepAspect is still using the same technique, but it’s more refined and well hidden. You won’t see any window popping up, and your compilation results will be reported nicely on your Visual Studio.

SheepAspect Query Analyzer

I have announced SAQA before, but this is the first time it has ever been released. SAQA’s releases will roughly follows the release cycle of SheepAspect, but it’s distributed as a separate download. You can download SAQA for SheepAspect Prevew-2 here on the project website.

Factory Per Aspect

Aspect factory determines how your aspect classes are instantiated during runtime. In the previous version, aspect factory was defined globally.

AspectFactory.Current = new StructureMapAspectFactory(structureMapContainer);

But there are times when you need to use a specific factory for your particular aspect. For example to instantiate your aspect from attribute declaration, or to instantiate from web-request (model-binding) or client cookie. New in Preview-2, now you can define your factory on a per-aspect basis.

public class MyAspect

If no particular factory specified for your aspect, SheepAspect will resort to a global default factory.

AspectRuntime.Provider.DefaultFactory = new StructureMapAspectFactory(structureMapContainer);

That’s right, you’ve just seen AspectRuntime there. It’s a new addition in SheepAspect Preview-2 that gives you access to the runtime environment of your aspects. You can, for example, switch off all your aspects (or a specific aspect) for unit-testing purpose, or even to replace your aspect with a mock. You can inquire the lifecycle of your specific aspect, or even change them (e.g. from Singleton to PerThis). You can ask for the instance of a specific aspect for a particular jointpoint, and so on. It gives you a flexible and dynamic control upon your aspect-orientated runtime behaviors that can’t be scripted during compile-time alone.


This is also the first release since the project changed its name from SheepAop. So if you’re using Preview-1, the upgrade path to Preview-2 will be a breaking and rocky one. But I’m very excited about this release, I’d strongly urge to to upgrade if you’re already on Preview-1, or to start trying out and play around with SheepAspect if you haven’t. So go on, it’s only a NuGet away 😉

These preview releases have always been about giving people an early access to gather as much feedback as I can. So any comments/issues/suggestions, as always, would be greatly appreciated 🙂

[More about SheepAspect]


10 thoughts on “SheepAspect Preview 2!

    1. Can you clarify what you mean by integrating the configs?
      You can integrate integrate Castle Windsor to manage aspects dependencies using a custom AspectFactory. I wrote a post about this on The API has changed slightly though. The current way to set a default AspectFactory is now from AspectRuntime.Provider.DefaultFactory. Please let me know if you are having any difficulty.

    1. SheepAspect doesn’t use Newtonsoft.Json library. Do you perhaps mean SheepJax (which is already using the most recent NuGet release of Newtonsoft.Json)?

    1. Yes. On every advice object, there is a Priority property that controls the order in which aspects are applied. (Lower numbers applied first. Default=100).
      Unfortunately, this property has not been exposed directly on any of the attributes in the API.
      So for now, there is a workaround you can apply. You can inherit the AroundAttribute and override CreateAdvice method. Like so:

      public class HighPriorityAroundAttribute: AroundAttribute
         public HighPriorityAroundAttribute(params string[] pointcutRefs): base(pointcutRefs){}
         protected override IAdvice CreateAdvice(MethodInfo method, IEnumerable<IPointcut> pointcuts)
            var advice = (AroundAdvice)base.CreateAdvice(method, pointcuts);
            advice.Priority = 1;
            return advice;

      So in your aspect definition, instead of writing

      [Around("pointcutA", "pointcutB")]
      public void Advice(/*..*/){}

      .., you use your HighPriorityAround attribute

      [HighPriorityAround ("pointcutA", "pointcutB")]
      public void Advice(/*..*/){}
      1. Thank you, this is exactly what i was looking for.

        Do you plan on keeping SheepAspect evolving in the future?
        I ask that because i REALLY like the way it works, compared to other AOP frameworks.
        As far as I know, SheepAspect is one of the only C# AOP frameworks that doesn’t require
        you to modify the code on which aspects must be applied.

      2. Thanks for taking interests in the project.

        There are 2 things regarding the current situation of the project:

        1. Presently I am not working on any commercial project that justifies the use of aspect-orientation, which is a very important thing to have as a test-bed for SheepAspect to keep evolving into production-strength. I will be more than happy if people do use it and ping me suggestions on what improvement they would like to see. But I definitely wouldn’t recommend using it for any production purposes at this stage.
        2. I am considering of remaking SheepAspect so it works on your source-code during pre-compilation, instead of the current implementation which processes your binary during post-compilation. The reason is because I quickly realized that, unlike java, C# language has grown to a stage where the compiled IL is getting less and less faithful to the original source-code that you write. It means that when you write your pointcut queries, you’ll find that you often subtly miss many targets that you were initially expecting, because C# moves your original code around (to different methods/classes), especially if you use delegates, lambda-expressions, yields, and more increasingly with the future async/await in C#5.
          Defining your aspects based on compiled IL of your code has proven to become a less and less predictable exercise for C# developers. This approach works well on Java, but apparently not so on C#.
          Now that Roslyn project has become public, I plan to remake SheepAspect to run directly on the source-code (not the binary). But there is a MAJOR drawback: you can no longer apply aspects on compiled binaries (e.g. third-party libraries). This is a significant drawback, and I will write a post about it to gauge people’s opinions about it.

        Any thoughts?

  1. Thank you for this detailed response. I learned important stuff here that will surely modify my plans.

    I wasn’t aware of all the effects that compiler optimisations could cause.
    I will also wait for a stable release: at the final i would really like to use AOP in my production application.

    I’m currently doing different experiments with DI and AOP. (I first tried AOP using Castle DynamicProxy)
    I’m using a copy of the codebase of a real production application, refactoring parts of it to remove dependencies and
    spot where aspects could be applied.

    As of now, I coded maybe 5 different aspects with SheepAspect: Thread Synchronisation, Thread Security/Principal assignment and check, Logging, Exception Handling and Audits.
    I’m lucky enough to have the source of all the dependencies that I plan to add aspects to.

    Suggestions: There is one great thing that PostSharp does: Adding attributes to classes and methods by using an aspect named CustomAttributeIntroductionAspect.

    Other than that,
    SAQL is cool. You should keep something equivalent in future versions. Some other AOP frameworks require you to decorate the original code where aspects must be applied with attributes, and it sucks!
    SheepAspect’s dependency injection friendly API is great too. I integrated it with Castle Windsor in less than a minute.
    Aspects Lifetime: I really like this idea and I used it with my aspects.

    I do support your idea of using Roslyn in the future. I wouldn’t suffer at all from it’s major drawback (but here it’ll be different for everyone i guess).

    Have a nice day!

    1. Thanks Loupitek for the feedback, it’s very useful. I also appreciate you sharing your experience using it.

      And yes, a capability to infuse custom attributes to existing type/methods is indeed on my list. It would be implemented as an Advice.
      At the moment, there is only one Advice implemented in SheepAspect: AroundAdvice. There will be many other Advices available, the most important ones being:

      • Advice to add custom attributes to types/fields/methods/properties
      • Advice to add an interface (and its implementation) to existing types

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s