Also, is https://github.com/DarthFubuMVC/StructureMap3 where development is ongoing for SM3?

Thanks-

I am quite new in this IoC and DI, but after following Rob Conery’s MVC1 video with you and researching on other DI tools like Munq, Funq, Autofac, etc. I found that your API and documentation are the best and very helpful to most developers like me. In fact, the performance reported is acceptable and opinionated. Your “Gentle Quick Start” is really helpful coz I am using class library for my DAL and reference it into my MVC. You DSL is simple to follow. You don’t have to write huge documentation to add for the existing ones. Giving code samples for many scenarios plus certain tips could be the best move. My chain of application is Database–>DAL(Petapoco/OrmLite)–>WCF Web API/ServicesStack–>ReadWriteEndPoints–>Clients(Asp.Net MVC Controller/Mobile MVC/JQuery/Dojo). Thanks for your attention.

Additionally, having cleaner control over object lifetime would be nice. It’s not always convenient to pass around IContainers and right now cleaning up, say, thread locals (by calling new StructureMap.Pipeline.ThreadLocalStorageLifecycle().EjectAll()) seems a bit messy.

It’s a perfectly valid concern, and I think it’s a perfectly valid choice to opt for a completely explicit configuration model. In practice though, the convention based registration has worked out very well on many projects and all we’re doing here is pushing it farther. The explicit model certainly isn’t going away.

* “All someone has to do to break that model is create a new class with a closer matching name than my class” — The conventions are much less fuzzy than that, or at least they are in StructureMap. Besides, you’ve got diagnostics to unravel that kind of thing and making those very diagnostics much more helpful is a major goal of SM3. Most of the time you use convention based registration you are just gathering up N number of implementations of an IFoo anyway.

* You would never, ever just drop an assembly into production without running it through tests would you?

On that note, I’m also not excited about convention- or heuristic-based mapping. All someone has to do to break that model is create a new class with a closer matching name than my class. This has the potential to exhibit some frustrating side effects, which could be very hard to track down in production.

I realize a lot of projects are looking for alternatives to heavy-weight, explicit, file-based configuration. I just don’t want to see us trade in a serviceable inconvenience for a shiny new nightmare.

This is great news! I ALWAYS choose StructureMap when I can. The only times I couldn’t is due to the lack of Client Profile support when a project demanded it. That’s when I grab my second choice.

I really like the idea of having the main assembly work with the Client Profile with an addon (fatter assembly) for the Web dependencies.

Also, I’m glad to help with documentation, etc. for using SM with the standard .NET goodies (WPF, ASP.NET MVC). Although, I’m starting to dig into FubuMVC lately and would really like to just forget about WebForms and .NET MVC. Until then though, I’d help where I can.

Thanks for the great for Jerry.