What's the simplest IOC container for C#?

Most of them are actually pretty simple to learn, so I think that asking for the simplest container is not the best selection criterion.

Most of them are actually pretty simple to learn, so I think that asking for the simplest container is not the best selection criterion. As an example, one of the most advanced DI Containers is Windsor, but getting started with it is as simple as: var container = new WindsorContainer(); container.AddComponent(); var I = container.Resolve(); I'm not particularly suggesting Windsor over any other container, but my main point is that it shouldn't really matter. What matters is that you understand DI principles and structure your code in a DI-friendly manner and that you select a container that will not constrain you as you learn more advanced concepts.

Selecting the simplest possible container isn't likely to satisfy that.

StructureMap is very easy to get working and works very well and the site has a great set of documentation to explain why you would use IoC/DI etc.

– Greg Mar 25 '10 at 11:59 I've not tried Ninject for a comparison. I'm looking at Windsor at the moment which seems more advanced overall but getting running with it was still relatively easy. – Chris W Mar 25 '10 at 14:22.

This one: public class Container { protected readonly Dictionary> services = new Dictionary>(); protected readonly Dictionary serviceNames = new Dictionary(); public DependencyManager Register() where C : S { return Register(Guid.NewGuid().ToString()); } public DependencyManager Register(string name) where C : S { if (!serviceNames. ContainsKey(typeof(S))) { serviceNamestypeof(S) = name; } return new DependencyManager(this, name, typeof(C)); } public T Resolve(string name) where T : class { return (T)servicesname(); } public T Resolve() where T : class { return Resolve(serviceNamestypeof(T)); } public class DependencyManager { private readonly Container container; private readonly Dictionary> args; private readonly string name; internal DependencyManager(Container container, string name, Type type) { this. Container = container; this.Name = name; ConstructorInfo c = type.GetConstructors().First(); args = c.GetParameters() .

ToDictionary>( x => x. Name, x => (() => container. Servicescontainer.serviceNamesx.ParameterType()) ); container.

Servicesname = () => c. Invoke(args.Values. Select(x => x()).ToArray()); } public DependencyManager AsSingleton() { object value = null; Func service = container.

Servicesname; container. Servicesname = () => value?(value = service()); return this; } public DependencyManager WithDependency(string parameter, string component) { argsparameter = () => container. Servicescomponent(); return this; } public DependencyManager WithValue(string parameter, object value) { argsparameter = () => value; return this; } } } Usage: TestMethod public void NamedRegistration() { Container c = new Container(); c.

Register("zero"); IMathNode m = c. Resolve("zero"); Assert. AreEqual(0, m.Calculate()); } TestMethod public void AnonymousRegistration() { Container c = new Container(); c.Register(); IMathNode m = c.Resolve(); Assert.

AreEqual(0, m.Calculate()); } TestMethod public void AnonymousSubDependency() { Container c = new Container(); c.Register(); c.Register(); IFormatter m = c.Resolve(); Assert. AreEqual("$0.00", m. Format("C2")); } TestMethod public void WithValue() { Container c = new Container(); c.

Register("five"). WithValue("number", 5); int I = c. Resolve("five").Calculate(); Assert.

AreEqual(5, i); } TestMethod public void NamedSubDependency() { Container c = new Container(); c. Register("five"). WithValue("number", 5); c.

Register("six"). WithValue("number", 6); c. Register("add").

WithDependency("m1", "five"). WithDependency("m2", "six"); int I = c. Resolve("add").Calculate(); Assert.

AreEqual(11, i); }.

Be careful not to trip the "not a real question" or "read the FAQ" monster tho :) I think this question got lucky, or was posted while enthusiasm is high for this topic... – Merlyn Morgan-Graham Oct 2 at 19:43.

Munq is one of the simplest & very faster IOC container. Check out this article Introduction to Munq IOC Container for ASP. NET for comparison.

Its the fastest one. Image from the article. Cheers.

6 container performance is largely irrelevant, they're all fast enough for 99% of applications. – Mauricio Scheffer Oct 21 '10 at 14:47 If you're building a larger app then it matters a whole lot, believe me! Further comment on the image above, from the article, "smaller (number) is better".

But let me just add the performance rig the above is based on is pretty simple, its not registering thousands of interfaces. – Keith Nov 23 '10 at 8:42 Like Keith mention. Munq uses a HybridDictionary to speed it up, but it only works as long as there is less than 10 registrations.

Funq is faster when more than 10 registrations. Worth mentioning is that their focus is different. I have uploaded some tests results to iocbattle.com, Dynamo included is my own project which works much like Munq, but is about 10 times faster than both Munq and Funq when registrations are Compiled.

But if not using my own (of course :)) I would probably go with Funq/Munq or Autofac using Lambdas. – MartinF Dec 21 '10 at 4:22 I agree with Mauricio's comment. Compare the ticks needed by the container with the ticks lost waiting for IO to: open a SQL connection, read a file or even an external service.

– graffic Aug 12 at 6:56 10 registrations is nothing in a real-world app. I have large apps using Windsor with several hundreds components, and it's nowhere near being the bottleneck. – Mauricio Scheffer Sep 20 at 17:14.

I would use Unity. Its contained in the enterprise library, and has tons of hands on labs. Super simple.

msdn.microsoft.com/en-us/library/dd20310... Unity Hands on labs.

Wow, there seem to be lots. No obvious "most popular" then in the general "simple" category I'm describing? – Greg Mar 25 '10 at 12:01 Like Mark said, they are all quiet simple and do relatively the same thing.

Enterprise library is nice because a it comes with EL so you have it in your tool box, they have hands on labs, and people use it in production code. – Nix Mar 25 '10 at 12:09.

I suggest that you have a look at Ninject. It's easy to learn, and a light weight IoC container. This documentation is a good starting point, though I don't think it's all up to date.

There are several good options though. Check out e.g. This question for a (non . Net specific) discussion on different containers.

– Greg Mar 25 '10 at 11:54 Most IoC containers would be good to achieve that, but Ninject is one of the really agile containers that keeps things simple for you. – stiank81 Mar 25 '10 at 11:56.

Managed Extensibility Framework is part of . NET 4 scoring +1 in simplicty for not having to add an external dependency to your project. (There is also a version for older versions of the framework.) It can do a lot more than the average IoC container, but is quite simple to use: public static class IocContainer { static CompositionContainer container; public static void Compose() { // All .

DLL files in the bin folder. Var directoryCatalog = new DirectoryCatalog("."); // The . EXE file for this application.

Var assemblyCatalog = new AssemblyCatalog(Assembly. GetEntryAssembly()); // Aggregate . DLL files and .

EXE file. Var aggregateCatalog = new AggregateCatalog(assemblyCatalog, directoryCatalog); container = new CompositionContainer(aggregateCatalog); } public static void AddInstance(T instance) { if (s_container == null) throw new InvalidOperationException("Compose container before using it. "); container.

ComposeExportedValue(instance); } public static T Resolve() { if (container == null) throw new InvalidOperationException("Compose container before using it."); return container. GetExportedValue(); } } Declaring imports and exports using attributes: Export(typeof(ILogger) public class Logger : ILogger { ... } Export(typeof(IMyService)) public class MyService : IMyService { ImportingConstructor public MyService(ILogger logger) { ... } } Resolving an instance where all the magic happens: var myService = IocContainer.Resolve(); MEF will create an instance of Logger and then an instance of MyService providing the Logger instance as an argument to the constructor.

While I'm all for using stuff built into the framework (I have considered doing what you're suggesting), sometimes it isn't the right solution. MEF uses IoC concepts, but is not an IoC container. The dev team for it have stated that much themselves.

One is for plugins/addons to an application (MEF), the other is for loose coupling of the application itself (IoC). See this question - stackoverflow. Com/questions/216565/… – Merlyn Morgan-Graham Oct 2 at 19:39.

Simple Injector is (as the name implies) the simplest (shameless plug) (and it even outperforms Munq). Quote from the site: The Simple Injector is an easy-to-use Inversion of Control library for . NET and Silverlight.It solely supports code-based configuration and is an ideal starting point for developers unfamiliar with larger IoC / DI libraries Here is an example that equals Marks example.

// Configure var container = new Container(); container.Register(); // Usage var I = container.GetInstance().

It is simple in every way but actual use. Every framework integration is a manual step - which is great because then you get to see the man behind the curtain. But it isn't so good in convincing people as to why they need DI.

Magic often persuades... (btw I've tried it on one Asp. Net Webforms project, tho never committed my changes - I did browse all the other interesting integrations, tho). This would be a good framework if you already had one person on the team who has used more advanced frameworks, who was willing to take the time to help everyone learn IoC tricks.

– Merlyn Morgan-Graham Oct 2 at 19:29 Which is my case, btw :) One of the tricks to adopting IoC is getting your whole team to both understand and use it. – Merlyn Morgan-Graham Oct 2 at 19:38 @Merlyn: Making the whole team understand DI can be a daunting task indeed. – Steven Oct 2 at 21:24.

I find that TinyIoC is very simple and easy to use. Here is an example that is equivalent to Mark's example. Var container = TinyIoCContainer.

Current; container.AutoRegister(); var I = container.Resolve(); But I agree with Mark in his point that it shouldn't really matter which DI container you use.

I would recommend using MicroSliver. I should note that while I am the author of this library, like you, I came to a similar question after spending time with various IoC/DI containers. My purpose with this library was to keep it extremely simple, micro and non-intimidating.

I strived to achieve a DI container with minimal bloat and yet still work for 90% of the use cases. Instructions on how to use, in their entirety, are all found on the very concise home page. This IoC/DI container contains the essentials of DI and can work with any type of .

NET application including Metro . NET (WinRT). Should you look to expand, it also offers extremely simple extensions for ASP.NET MVC, RIA Services and Silverlight.

Last, but not least, you can easily install the library via NuGet.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.