Lamar has had some churn lately with me almost giving up on it, changing my mind, and look at that, publishing a very significantly improved version up to Nuget just now.
I just published Lamar v3.0 with some bug fixes and big internal improvements. This release is mostly significant because it eliminates Lamar’s previous reliance on Roslyn for runtime code generation in favor of a more common model that builds Expression trees and compiles dynamic lambdas — inevitably with the excellent FastExpressionCompiler for maximum performance and faster cold starts.
All told, Lamar v3.0:
- Has much faster “cold start” times compared to ❤
- Is faster across the board, but especially when internal types are involved. The very early user feedback is “holy moses that’s much faster”
- I think that we’re through with compatibility with internal types being registered into the container because the dynamic Lambdas don’t have to care about the type visibility
- Will use way less memory without the Roslyn dependency tree in memory
- Has far fewer dependencies now that some users complained about
There are no API changes to Lamar itself, but there’s now a different set of Nuget libraries:
- LamarCompiler — only has Lamar’s old helper for executing the Roslyn runtime compilation, but this is no longer referenced by Lamar itself
- LamarCodeGeneration — the
Frame/Variablemodel that Lamar uses to generate code and now Expression trees in memory. This is used by Lamar itself, could be used as a stand alone library, and has no direct coupling to LamarCompiler - Lamar itself
A touch of history…
I’ve been absolutely exhausted for years with maintaining StructureMap and dealing with user questions and oddball problems. I also knew it had some pretty ugly performance issues and it had been a massive pain in the ass force fitting StructureMap’s long standing functionality into ASP.Net Core’s new compliance requirements (that appear to have been made up by the ASP.Net team out of whole cloth with ZERO input from the major OSS IoC tool authors). I also knew from some experimentation that I wasn’t going to be able to fix StructureMap very easily, so…
Lamar was an attempt by me to throw together a new IoC tool that would mostly mimic StructureMap‘s public API (everybody has opinions, but there are actually quite a few people who like StructureMap’s usability and it’s had ~6 million downloads) and a large subset of its functionality. At the same time, I did change its lifecycle semantics and behavior to be ASP.Net Core-compliant from the very get go to head off more problems with that.
Lamar’s original model was based around using dynamic code generation and compilation with Roslyn. Woohoo, it was easy to use and I was able to get a large subset of StructureMap’s old functionality working over Christmas break a couple years ago. Unfortunately, that model doesn’t play well at all with internal types and my limited workarounds were pretty clumsy. It turns out that lots and lots of people and common frameworks like to put internal types into IoC containers (looking at you ASP.Net Core). So here we are. Lamar switched over to using Expressions compiled into Funcs like basically every other IoC container I’m aware of, but hopefully it starts fulfilling my real goal for Lamar:
Get folks complaining about StructureMap off of that and make my life easier overall by reducing user problems.
The Shade Tree Developer 
Good stuff. Yeah it’s a shame the asp.net core team didn’t take input from IoC container authors but I guess they were in a position to dictate terms and knew that open source IoC projects would adapt.. I’ve experimented with Lamar myself, and I liked it. The only thing stopping me from using it is no support for child containers – an area you have explained is a source of frustration / errors in structuremap. I think what would be useful is a feature comparison between Lamar and structuremap to help those considering the switch!
Hi Jeremy,
Thanks for all your hard work on this, this really is an amazing upgrade of Lamar, and makes a huge difference in performance and memory usage. I fully support your work keeping Lamar from becoming bloated like StructureMap. Personally I view overly complicated IoC setups as bandaids on problematic architectural choices, and while it may not be fun for people who rely on such functionality to hear that it will no longer be maintained, sometimes “tough love” is required :).
I would also like to thank you for your underestanding and patience when dealing with my issues on git, having once maintained a widely used opensource project myself I can relate to the feelings you described in the earlier blog posts.
Again, marvellous work, nice to have a modern take on the design sensibilities that made StructureMap such a beloved framework.
Wow, great work. Thanks for your work. We really appreciate your efforts and are very happy to use such an easy-to-use IoC framework.