Spring.Net is an application framework which has its roots in the Spring Framework for Java.

Now first of all, I know many developers have an averse reaction to the use of the phrase "application framework" and immediately reject such things without second consideration.  I always hear tales that begin like so: "Well, on this one project, we used an application framework and it ended up not doing anything exactly the way we wanted and we had to modify it anyways..."

Four thoughts on this:

1. No two applications are exactly alike.  If that were so, we'd all be out of jobs as software engineers because it'd probably have already been done before.  As well, no two application frameworks are alike (although on some level, Spring is interchangeable with Castle).
2. Spring, I have found, does not restrict me in anyway in terms of my solution design.  If anything, it frees me to use more flexible designs and allows me to create much cleaner and better designs.  Inversion of Control is your friend.
3. Spring includes the source.  Dude, if it doesn't do exactly what you want it to, you are 100% free to modify and reuse it (and maybe even resubmit it to the project if it's well written and useful).
4. The documentation and development team on Spring (and Castle to a lesser degree) are great.  The documentation is very thorough and well organized and the developers are constantly monitoring the discussion forums and reaching out to users.  Many times, with any sort of large library, you may be under the impression that it doesn't do something (thus leading you to believe that you have to write it anyways and believing that it was pointless to use the framework), but it may actually be the case that you simply haven't found the facilities in the library to accomplish your task.

On top of this, the support forums and developers working on the framework are great resources for hashing out design ideas (outside of one's normal circle of peers).

Yes, it's true, Spring requires the use of what can become massive XML configuration file(s).  Yes, it can be difficult for first timers to grasp inversion of control, understand what exactly it is that Spring offers, and in general, find anything in Spring that would significantly make one's life easier as a developer without a learning curve.  Yes, Spring is huge; it encapsulates a lot of "stuff" that can be confusing and seem like bloat one's first time encountering it (I myself only ever use a small subset of the features of Spring).

However, in the end, I think Spring brings so much to the table (too much for me to list here), it's hard to discount it without at least giving it a real evaluation.  For any sort of non-trivial application, Spring allows the designer to add much more flexibility and decrease the complexity of the codebase by encapsulating a lot of the dirty work.  (I would agree that there is a complexity cutoff where if your application sits below this cutoff, it's simply not worth it to include Spring in the discussion, as the time it takes to understand and find its usages in your scenario would not be worth it).

I've been using Spring for almost a year now and I simply can't imagine writing an application without it.  With the latest release, the introduction of the data access library, Spring becomes even more compelling by removing a lot of the boilerplate code that one would write when performing data access.  Admittedly, in a sense, it is a replacement of one set of boilderplate code for another, but it is a much more elegant design than using raw ADO or even Enterprise Library for that matter.  Spring introduces the usage of a delegate/callback pattern for "rendering" the returned data rows and sets into domain objects and sets.

I use the term rendering because this is the same exact pattern that I've been using with regards to the JavaScript that I've been writing for my AJAX enabled applications.  It's an elegant pattern that, in JavaScript, allows for decoupling of the code to retrieve that data from a web service and the code that renders the data.  In a sense, Spring does the same, except, instead of rendering a UI, it renders a domain object (or set) using the delegate, which decouples the data access plumbing from the building of the domain object.

Having used NHibernate previously, I have to say that in many cases, I still prefer performing my own data access code and domain object rendering as it allows me much more flexibility and control.  There is less processing overhead and not to mention (when I last checked) NHibernate still does not natively support generic types.

I've mostly been sticking with Enterprise Library, which is basically just a step above raw ADO, but I'm gonna give this a shot since it's yet another step or two above Enterprise Library.

On another note, it seems like Microsoft's Patterns and Practices Group is finally releasing the next version of Enterprise Library.  In a sense, EL is a "necessary evil".  As far as 2.0 goes, I cannot say that it does anything particularly better than other libraries that fill the same purpose as any given block, but what it does do is it encapsulates multiple functional spaces (logging, data access, exception handling, configuration) into one.  In addition, having the Microsoft Seal of Approval also helps with acceptance.  As an example, the rolling flat file trace listener has had a counter part in log4net since I've been using it (over 1.5 years now).  The data access application block, while it does clean up data access code, is still pretty close to raw ADO.Net usage patterns; in other words, it brings almost nothing to the table (almost; I still endorse it over raw ADO.Net to be sure).

It'll be interesting to see what this Object Policy Application Block actually does.  It seems like it's conceptually similar to Spring's IApplicationContext or Castle's Windsor Container.  I'm not one to latch onto a product simply because it's from Microsoft's P&PG, so I'm hoping they can actually bring something new to the table to make their library more compelling than Spring or Castle (both of which are much more mature by now and encapsulate a far greater set of features).

As for the any concern over the longevity of Spring and Castle, I feel pretty confident that what happened to NDoc, will not be happening to Spring or Castle.