I’ll be honest, I haven’t worked much on StructureMap since I originally shelved my original 3.0/rewrite work in the summer of 2010 — and yes, the documentation is almost worthless. Now that FubuMVC reached that magic 1.0 mark I’m turning my attention back to StructureMap for a bit, but I think I want some feedback about what I’m thinking right now.
For background, read:
- Kicking off StructureMap 3.0 — I just re-read this, and I’m still thinking all of the same things here and all the feedback is still valid.
- Proposed StructureMap 2.7 Release
A month ago my plan was to do a small 2.7 release on the existing codebase to remove all the [Obsolete] API calls and grab some pull requests along the way. Having done that, I would then turn my attention back to the 3.0 codebase where I planned to essentially rewrite the core of StructureMap and retrofit the existing API on top of the new, cleaner core. A week or so into the work for the 2.7 release and I’ve changed my mind. First off, by the rules of semantic versioning, I should bump the major version to 3.0.0 when I make the breaking API changes. Secondly, I’m coming around to the idea of restructuring the existing code in place instead of a full rewrite.
To reiterate the major points, the 3.0 release means:
- All [Obsolete] API calls are going away
- Removing the strong naming — if you absolutely *have* to have this, maybe we can make separate nuget packages. I suggest we name that “structuremap.masochistic.”
- Move to .Net 4.0. I don’t think it’s time to go to 4.5 yet and I don’t really want to mess with that anyway
- Taking a dependency on FubuCore — if that causes pushback we’ll ilmerge it
- Streamlining the Xml support
- Rewrite the “Profile” feature completely
- Make nested containers not be a crime against computer science
- NOT adding every random brainfart “feature” that Windsor has
- Make it faster
- Make the diagnostics much better
- Removing some obscure, clumsy features I never use and really wish you wouldn’t either
Additionally, we have a new “living documentation” infrastructure baking for the Fubu projects. I know some work already happened to transfer the StructureMap docs to Jekyll, but I’d far prefer to publish on the new fubu world website whenever that happens.
For right now, the 3.0 branch is in the original StructureMap repository at https://github.com/structuremap/structuremap/tree/three.
The Shade Tree Developer 
I’m not excited about a FubuCore dependency. What is the gain? I like that StructureMap.dll stands by itself.
There’s a fair amount of overlap between Fubucore and StructureMap now that I’d like to eliminate. There’s also some better type conversion utilities in FubuCore that I think I’d like to be in StructureMap OOTB as well for the way that we do configuration in the fubu projects.
As I said, your the 2nd person who’s been against the FubuCore dependency. Simple ilmerge and that little problem goes away.
I have no problem what so ever with a dep on FubuCore … if I really had a problem with deps I would have stopped using any open source packages.
I’m not sure why people are against it, but I guess there are some concerns. Just don’t make it as bloated as CastleWindsor is … SO MUCH USELESS crap that should have been in seperate projects if you ask me.
Keep up the good work.
Make it three for at least ILMerging — Structuremap is really a building block, I’m not so sure I like my building blocks having visible building blocks.*
* yes, I do admit we all have building blocks weather we like it or not.
I also prefer to keep StructureMap as a self-contained component if possible. I often have to look at old, legacy code that relies on many external libraries and have no one to break down their (often hidden) interdependencies. It becomes an archeological exercise to determine what has to stay and what can be safely ejected. Containing StructureMap in a single DLL would help avoid that in the future.
That’s the prevailing sentiment, but I keep seeing more and more duplication between the lib’s. I’m dodging the decision right now, but I’m leaning toward doing an ILMerge w/ FubuCore into StructureMap.
The “Kicking off StructureMap 3.0” link seems broken to me 😦
IMHO this approach will work a lot better. Maybe I am wrong, but that’s my hunch anyway.
And I’m hoping that you’re right;)
With regards to your point on removing strong naming (liked the S & M rename btw 🙂 ), I’ve been in several corp environments where they require their projects to be strong named, thus placing that constraint on dependent assemblies as you know. What’s your thinking behind that?
Strong naming and OSS packages delivered via Nuget are a nasty combination in my experience. My feeling is that strong naming hurts us more than it helps in terms of adoption and trying to get started on a new project.
I *am* open to a parallel release of a signed version of StructureMap.
What do you think about the approach that James Newton-King is taking with Json.NET by only changing the assembly versions on major releases, and not on builds, and instead just changing the assembly file version. (http://james.newtonking.com/archive/2012/04/04/json-net-strong-naming-and-assembly-version-numbers.aspx). Is that a possible solution for this issue?
I think you probably don’t follow me very closely on Twitter;)
I hate the way that Json.Net does it too. It softens the blow a little bit, but making the nuget and file versions vary from the assembly version just causes a different set of headaches. That strategy is exactly what the Nuget team themselves seems to be suggesting, but put me down as hating that.
Twitter? What’s that? 😉
Point taken. I’m not a proponent of strong naming either, but I’d just hate to see adoption of SM3 be hampered in the big corporate world because of rigid corp standards. Maybe this isn’t even a nuget packaging issue anyway, because come to think of it, the corporations I’m thinking of don’t even have access to Nuget feeds anyway (although that’s increasingly becoming difficult to maintain that position). Maybe the solution is just offering a strong named build of SM and not publishing it via Nuget, because I’m guessing that would meet the large majority of the needs of the strong naming proponents.