A long time ago I also used structuremap to automatically wire up default implementations of interfaces, which reduced the need to write boilerplate code enormously. It also helped separate concerns because separating out interfaces means I could concentrate on only the specification of the class.

That goes inside another thin bag for safe carry. If I'm visiting somewhere new and carrying other things, bag-in-bag works well; leave the day bag in the conference room, the thin bag with the laptop comes with me.

1) a dependency on a third-party service provider that publishes the dependency. So long as that service provider is current, the dependency should be maintained 2) short-cut to code i don't want to write

I have no arguments with (1), there's a business reason and the lifecycles should match. However, I should still expect major version breaking changes in order to keep my application running. For (2), the wins are less clear, more dependenent on the perceived complexity of what I can avoid writing.

Taking on any kind of dependency means that someone else can dictate when I need to spend time updating and testing changes that don't add anything to my product. Taking on a third-party dependency is always taking on a responsibility to maintain a codebase or the risk of not doing so.