So StructureMap 3 hasn’t really gotten going again, but I still have intentions of doing so this year. In the mean time, I’ve got a batch of pull requests stacked up in the StructureMap 2.6 codebase and it’s time for a new intermediate release. At this time, what I’d like to do is rev up to StructureMap 2.7 and do this:
- Take in all the outstanding pull requests
- Remove all [Obsolete] API members
- Mark as [Obsolete] some various parts of the registration API that I know that I will not support in 3.0 (conditional construction comes to mine)
- Mark all StructureMap attributes except for [DefaultConstructor] as [Obsolete] as I think we will dump all the circa 2003 attributes that you used to need to use.
- Remove the strong naming because it’s death in combination with Nuget. If this is an issue for you, I will happily take a pull request to make a separate nuget package for a signed version of StructureMap
- Ideally, I’d like to clean up the more coarse grained unit tests in a new namespace called “Acceptance” in order to get these ready for usage in StructureMap 3 and maybe provide a level of living documentation for later.
- MAYBE — take a look at cleaning up the exception stack traces to give you more contextual information about where StructureMap caught an exception. We lost a lot of contextual information when I eliminated the Reflection.Emit usage in favor of compiling Expression’s.
Thoughts?
The Shade Tree Developer 
Sounds great, Jeremy. As to #7, while getting good exception stack traces would be great, I would suggest your time is more valuable spent on code and thoughts that would likely not be an issue in StructureMap 3. Yeah, it’s a pain point, but those of us using SM for a while now, know how to figure out what’s wrong when an exception is thrown. I’m not sure how many newcomers to SM there are to put effort into this for 2.x. Just my take on it.
Glad to see some momentum for 3.0 again. 😉
*I’m* the one who wants the better stack trace. I’m trying to make it easier for folks to understand the context in which a structuremap exception exists. I have trouble discerning what’s going on sometimes, so I have to assume that other folks do too.
Ah, okay. I can understand that. I do struggle at times, but for the most part, it ends up being the same similar mistakes (like forgetting to register a specific service that isn’t handled by the standard scanner conventions).
What can we do to help?
Chris,
Honestly, starting those new acceptance tests would be hugely helpful — both for 3.0 compliance and also because I think we can use them in situ as the sample code in a new set of StructureMap docs.
Otherwise, this release is just some boring work cutting new interfaces behind the scenes to remove the strong naming.
If you’re interested, maybe going at the better error messages? I’d like to take the BuildStack business and use that to show you a contextual breadcrumb trail of what StructureMap was trying to build when it threw the exception.
Yay! 🙂