Last week, Alex Papadimoulis joined Gael Fraiteur on the PostSharp Live Webinar to talk about NuGet, the popular open-source library package manager for .NET, and show how it helps developers escape from "dependency hell" while discovering new third-party libraries.

Attendees learned:

  • how developers are successfully using NuGet;
  • why PostSharp chose NuGet for deployment management;
  • what deployment management pitfalls to watch out for; and
  • when to consider solutions like private repositories.

Watch the recording and learn how to leverage NuGet and private repositories to improve your enterprise architecture.


Q: How do you specify dependency on a version range?

A: NuGet documentation shows how to do that:

Q: When you install the NuGet plugin by default it is configured to pull from the public repository. How do you prevent users from pulling packages from this public NuGet repository? Is this a specific configuration change?

A: What you have to do from a training standpoint is instruct developers to add a package source. Go to package management settings, uninclude the official package source, and add in your own corporate library. There is no good way to prevent developers from doing it themselves, so it's important to monitor your packages.config file for changes to it to ensure a bad package isn't added.

Q: How do you deal with scenarios where two packages depend on the same third package, but they depend on different versions of that third package? Visual Studio will only include one of the versions, and you will get a runtime failure.

A:This becomes tricky. NuGet attempts to add a binding redirect to mitigate the problem, but it can cause more problems than benefits. My advice is to monitor the versions that are added and that you're redirecting appropriately.

Q: Is it possible to configure NuGet for projects independently of Visual Studio solutions? What if projects appear in multiple solutions?

A: NuGet works fine if you keep your configs simple but can complex things can get a little hairy depending on your configuration. has a packages.config file, and some of the default locations for the packages file

Q: Can standard MS packages (e.g. MVC 4 bits) required by the new project dialog be routed via a private NuGet repository to make the selection / deselection of the public NuGet repository in the developer machine?

A: Yes. Select the Package Manager option in Visual Studio, where the available Package Sources are displayed, and select the source you want to use. NuGet will use whatever package source you select rather than the public source.

Q: What's the best way to enable package restore on a bulid server?

A: Package restore adds a folder to your Visual Studio solution and does all sorts of weird things with it. We recommend users not use NuGet package restore and instead have a NuGet install as part of your build server plan. We recommend this to our customers since NuGet package restore doesn't work with PostSharp. Create a build step that includes calling NuGet install before calling MS build for every file package.config you find in your source tree. It's much more reliable.

Next week’s guest on the PostSharp Live Webinar is Alex Papadimoulis, founder of Inedo, makers of the DevOps platform - BuildMaster, and The Daily WTF, a fun website dedicated to building software the wrong way.

On Thursday, July 11th (09:00 PDT, 12:00 EDT, 16:00 GMT) Alex will speak about NuGet, the popular open-source library package manager for .NET, and show how it helps developers escape from "dependency hell" while discovering new third-party libraries.

There are pitfalls with the tool however and Alex will demonstrate how, with NuGet, what works in the open source-world doesn't always translate well to enterprise development.

Webinar attendees will learn:

  • how developers are successfully using NuGet;
  • why PostSharp chose NuGet for deployment management;
  • what deployment management issues to watch out for; and
  • when to consider solutions like private repositories.

If you have ever wanted to learn how to leverage NuGet and private repositories to improve your enterprise architecture be sure to sign-up for the next PostSharp live webinar.

Seats are limited so reserve your spot today!

See you there!



The benefits of unit testing are numerous. When aspects are involved, Matt Groves believes keeping them "thin" is key to keeping your code easy to unit test and he explores some of the implications of unit testing when a post-compiler tool is involved.

Gael Fraiteur joins this final episode in the AOP in .NET series to give his differing opinion about the relevancy of "thin" aspects and speaks about a set of practices that can be used to create efficient tests of aspects.


Q: What would be the best way to inject the cache provider VIA an IOC container? (e.g. Autofac/Unity)

A: Whatever container you wish to use is fine. In my example I just new them up directly but in reality you shouldn't do that. In structure map you could say:

if (!On) return; 

As long as you're not tying it to a specific implementation, you're just asking for something that implements the interface. This is known as the service locator pattern.

Q: Gael, you mentioned in your presentation that one can't test an aspect in isolation of a target. Isn’t that exactly what Matthew just showed us?

A: Gael – yes, but Matt showed it in a very specific case using compiler internals to do it by instantiating the execution arguments that are being passed to the aspect. In the case of OnMethodBoundary Aspects, this is very simple to do, but if there are changes in methods or invocations it can become quite complex.

Matt showed how to isolate the aspect completely from the aspect framework with the notion of thin aspects but to me the cost of doing so is huge. There is the abstraction that is added on top of the aspect which isn’t justified because test coverage is worsened and the meta data is part of the input. Just as you wouldn’t test a method without an argument, you wouldn’t test an aspect without a target.

Matt – what I tested in isolation wasn’t an aspect but rather the advice or the actual logic of the aspect.

Gael – Matt’s approach may work in simple cases but I would be curious to see how it works in complex aspects, including aspect combinations.

Q: Why would you use a static IOC resolution instead of using the service locator with each call of "OnEntry"? (in the logging example)

A: This is a matter of optimization. Logging is very performance sensitive, because it’s invoked at a very high frequency, so I would avoid resolving dynamically but this is entirely up to you. In documentation, I show several approaches where the service locator returns a delegate that may be re-evaluated each and every time (or not, depending on your preference).

There is no general rule or best practice here, it depends on what you want to achieve in each situation and the tradeoffs between architecture and performance.

Q: Gael, you mentioned in your presentation that you can’t unit test build-time logic because PostSharp performs code weaving at compile-time. For a consumer of a class or a framework, why would I be concerned on how the deliverables are made instead of how they are used?

A: It depends on who the consumer is. In large teams, you’re delivering aspects to the rest of the team and not the end customer. With some of our largest customers 10% of the team build aspects and the other 90% consume the aspects. In those cases, if you want your team to be more productive then you need to check that the aspect has correct build-time behavior. Then the problem is: how to test validation.

If however your aspect never emits build-time errors, then run-time testing may be sufficient.

Q: Couldn't you unit test the aspects advice the way Matthew suggests, and then integration test the combination and ordering of method calls of the aspects the way Gael suggests? Do these techniques really need to be mutually exclusive?

A: Gael – it depends on what your objective is. If your objective is to decouple the framework from the aspect, then Matt’s approach may be useful. However, if the objective is to do good testing in as little time as possible then why would I add complexity and decouple the framework from the aspect? I don’t see the benefit in terms of architecture and time-savings.

Matt – Gael and the PostSharp team take a different approach than I would because they’re writing aspects for the general public to consume and not just my team.

Q: In the case of injected concerns/dependencies for aspects, would you use a fake resolver?

A: Matt – in my case the aspect was thin enough so I didn’t have to use a fake resolver. What I did instead was to pass-in mock objects directly, injecting them myself.

Gael – you should have your resolver work differently, depending on the context. In production, you would involve your real resolver and in testing you would add rules. and according to the context to which the aspect is being applied, it would return a different implementation of the service. these are all options to consider.

Q: Have any of you used something like nCrunch with PostSharp?
Matt – I’ve used nCrunch before, it’s a great test runner tool, and haven’t had any problems with using it and PostSharp together. However it’s been a while since I last used it.

Many thanks to Matthew Groves for the wonderful 5-part series. We wish him much success with his new book, Aspect-Oriented Programming in .NET, out this month. You can see Matt speak and catch up with him in person this summer at Louisville .NET Meetup Group and CodeStock.

Alex Papadimoulis of The Daily WTF fame will join us on June 27th for the next PostSharp Live Webinar to talk about NuGet, deployment management issues, and private repositories as a possible solution.

More on that coming very soon.