I am considering building a custom DI container, as it occurred to me our own custom providers or even the out-of-the box providers do most of the work. I had been describing the 'provider' to other coders as a powerful factory for a long time. Looking into Ninject, I found they describe how their DI bindings are resolved by a provider:

snip

Okay, so remember when we said type bindings were from a service type to an implementation type? Well, we lied. You caught us. Type binding is really a little bit more complicated than we let on. Rather than being from one type to another, bindings are actually from a service type to a provider. Simply put, a provider is an object that can create instances of another type. It's like a factory, but specifically designed to work with Ninject.

/snip

Ninject is referring to their own concept of provider, but replace that with an ASP.NET provider or any one that pulls in XML config and you have the beginnings of a tiny DI framework.

A repository of well known FOSS is located at dotnetit.org. This includes Apache Xerces (an XML parser including DOM and SAX implementations), Apache Xalan (an XSLT and XPATH parser and processor), regexp libraries, cryptography libraries, etc.

An open source alternative .NET IDE is #develop. This project is coming along fast, and includes a library NRefactory that parses C# and VB.NET and IMO has a superior abstract syntax tree model than the CodeDom.

If broken it is, fix it you should is a great MSDN blog heavy in content that walks through debugging techniques for memory leaks, crashes and the like, using windbg and perfmon. Great place to learn how to poke around your heap from the command line.

The standard corlib doesn't provide a good library to creating zip files (while it does do zip compression). If you'd like to do this but don't want to use a third party check out Jon Galoway's blog. In short, use the J# library and java.util.zip.

Myca designed her site from the ground up, so this one involved just some technical legwork to pull together the components. I'm pleased on how it came out so take a gander @ mycathompson.com. Otherwise its been a whole year since my last post, but stay tuned 'cause I have a new pet project and its gonna be fun.

I got an email from someone who couldn't compile GibberMonkey 0.1, after referencing spidermonkey-dotnet 0.2.0. GM code has undergone some changes since the 0.1 binary release. It and SM.NET 0.2 are in the process of being refactored to present a good API to the library user. Enough catchup. The latest code from TFS on both projects will compile together. To be specific, the GM changeset 9678 will compile against the development branch ($/spidermonkeydotnet/development/spidermonkey-dotnet) SM.NET changeset 21914. Also, if your a codeplex.com member you can simplify all this by joining the project and hitting the TFS and mapping these projects to your workspace.