Lately I’ve been toying around with Amazon’s cloud platform in .Net using the Amazon Web Services SDK (AWSSDK). Also along for the ride has been Ninject, which is a pretty awesome dependency injection framework. So if I want to have a class have a constructor dependency from an AWSSDK client class, that has to be wired up the same way your regular non-Amazon classes are, in a NinjectModule.
Fortunately, there are interfaces for all the client classes in AWSSDK, albeit with an unusual naming structure. The class for calling the Simple Notification Service is called AmazonSimpleNotificationServiceClient, but it’s corresponding interface is AmazonSimpleNotificationService. Note the loss of ‘Client’ on the end, and that it doesn’t begin with a capital I which is the typical norm for C# interfaces. Anyways, that won’t prevent you from using them in Ninject. The problem is that there are 20, count ‘em, 20 of these client classes. You could manually write all 20 in individual calls to Bind<T> but where’s the fun in that?
This module will load them based on their aforementioned naming convention.
public class AwsModule : NinjectModule
public override void Load()
var awsAssembly = typeof(AWSClientFactory).Assembly;
var amazonClientTypes = from t in awsAssembly.GetExportedTypes()
where t.IsClass && t.IsAbstract == false
&& t.IsPublic && t.Name.EndsWith("Client")
foreach (var clientType in amazonClientTypes)
string clientTypeName = clientType.Name;
int clientIndex = clientTypeName.LastIndexOf("Client");
string expectedInterfaceName = clientTypeName.Remove(clientIndex, 6);
Type interfaceType = (from clInterface in clientType.GetInterfaces()
where clInterface.Name == expectedInterfaceName
if (interfaceType != null)
Note that this results in binds that end up resolving to their default constructors, not any of the overloads that take credentials or config objects. As is, the above code will use credentials from your app.config/web.config file by searching for AWSAccessKey and AWSSecretKey in your appSettings section. Which I’m fine with. I could have this or another module bind AWSCredentials to anything that derives from it, like BasicAWSCredentials. And similarly for ClientConfig if that’s your bag.