I'm a big fan of Aspect-Oriented programming (AOP). I like not repeating myself. For a long time, PostSharp has been my tool of choice for making short work of AOP in .NET.
Sadly, PostSharp is now a commercial product, and one that has a pricing model beyond my team's reach.
Now, I don't have any heartburn paying for a good commercial product. I fully support paying for quality software. But I've always thought there is room for a similar tool to do AOP without needing compile-time code weaving.
The commercialization of PostSharp was my catalyst for starting an open source project to develop a suitable replacement. The aim of the project is to use the familiar attribute-centric convention for method interception.
Thus... Snap was born! Simple .NET Aspect-Oriented Programming.
There are a few different ways you can approach AOP using .NET. Tools like PostSharp use a technique called code weaving. That's a fancy way of saying a tool changes your code and PDB files when you build your project. It's a clever way of manipulating the output IL, and it's quite powerful.
Many people dislike code weaving, though, because it feels too much like black magic, and that bothers some people.
Even if I thought code weaving was the right approach for a replacement tool, it begs the question whether code weaving is necessary for AOP.
Inversion of Control is Everywhere
If you're a .NET developer who's got a heartbeat, it's inevitable that you've heard about Inversion of Control (IoC) and Dependency Injection. If those phrases are new to you, hit the pause button here and go Google (or Google with Bing) IoC.
IoC and DI aren't new concepts, but they have had a lot of time in the spotlight recently. I think this is due, in part, to ASP.NET MVC gaining in popularity, and the fact that the MVC team has done a world of good to highlight the framework's testability.
So, since IoC and DI are all the rage, I set out with a simple mission.
Snap is an AOP framework that works seamlessly with your favorite IoC Container.
As of this writing, Snap works with five IoC containers including:
- Castle (and Windsor)
Not bad for an initial release, huh? The whole point of Snap is to NOT get in your way. You're probably already using one of the many IoC containers out there, so why not just make a fuller use of that tool? The whole point of Snap is to make AOP Simple. That's why Simple is in the name. It's a reminder that Snap should always be easy to use.
So I have 5 IoC containers working. But there are many more IoC containers out there, and I'm looking for help to get them integrated, tested, and up to par.
That's where I need your help!
A Social Experiment
I've been writing articles on CodeProject for a long time. CodeProject is a website I'm very fond of, and the kind folks who run it are great to work with.
But as much as I love this website, there's one big piece missing: Collaboration.
Usually when I write an article for CodeProject, I take my little demo project, zip up the contents, and upload it with the article for you, the reader, to download. That's fine for educational purposes. But I'm after something different this time.
I want to build a team around this project.
I don't just want to post code and wait for you to review it and vote on how much you like it. Let's face it, half of your vote is how much you like someone's writing.
What I want is participation! I'm looking for you to contribute, participate, get involved, help out, and otherwise help build something great!
That's the experiment - using the amazing pool of resources here on CodeProject to help start a team.
Since CodeProject doesn't have any way to manage code, I set up a public repository where people can easily get, modify, and commit changes to the code base.
I've chosen GitHub as the project's home. If you're not familiar with Git, it's a fascinating tool. Git is a distributed, disconnected source control system. It makes branching and merging painless and simple. And it's BLAZING FAST too.
Now I know that you're a .NET developer. And when you hear that Git is largely a command line tool, you'll probably stop reading the article.
Don't leave... Keep reading... there's hope!
Yes, Git is primarily a command line tool. But let me offer a few points as to why that shouldn't scare you away.
- There's only a few commands you really need to know and use.
- Git has wonderful documentation.
- Git has lots of help built right in
- There are GUI tools to help.
- There's nothing wrong with learning something new as a developer. Expand your horizons.
- There's so much power in Git that you'll forget all about the command line.
- You can integrate Git into Visual Studio (Check out Rob Conery's TekPub videos on Git).
I'm personally using a tool called msysgit which is both a GUI and command line tool for Windows.
Joining the Team
So, are you ready to dive in? Great! Let's start with the basics, Q & A style.
Q: Where is the Snap website?
A: The web site is http://www.simpleaspects.com/ where there's general information and a blog.
Q: Where is the source code?
A: The source is on GitHub at http://github.com/Acoustic/Snap
Q: Is there documentation?
A: There's an official project Wiki at http://wiki.github.com/Acoustic/Snap/
Q: Is it okay for me to contribute to the project?
A: YES! That's the point of the project.
Q: Are you using reflection?
A: Yes, but Snap uses a library called Fasterflect. It's tons faster than traditional reflection.
Q: Aren't there code weavers out there other than PostSharp?
A: Yes, but most of those projects are dead or target old versions of .NET
Q: Is Snap easy to use?
A: Yes. Here's a complete sample configuring Snap to work with
ObjectFactory.Configure(c => c.For<IMyType>().Use<MyType>());
var badCode = ObjectFactory.GetInstance<IMyType>();
public class MyType : IMyType
[HandleError] public void InterceptedMethod()
It's just that easy!
Spreading the Word
I realize that not everyone is going to have time to commit to an open source project. That's a tall order. Even if you don't have the time or the interest, I do hope that you find Snap to be a useful tool.
If that's you, then help spread the word. Maybe you know someone who'd like to participate. Point them to this article or to the GitHub site.
The project won't work without a community!