Sure - the IServiceProvider interface has been part of the Framework since 1.0. This isn't DI as it is typically discussed here (using a "kernel"), but it is IoC using the Service Locator pattern.
If you dig into any of the Windows Forms Designer code, you'll see it peppered liberally with lines like this one:
IDesignerOptionService service =
(IDesignerOptionService)this.GetService(typeof(IDesignerOptionService));
If you're working with a Component, then you get access to this via the Site property. It's quite common and practically required knowledge when creating custom controls.
This is Service Location, textbook example. You've got a generic IServiceProvider
that hands out abstract services you request by service type. If you ever want to create custom designers - smart tags and so on - then you need to know all of this. It's similar for ASP.NET as well.
P.S. Please don't use IServiceProvider
in new code. It's a very old, non-generic interface. If you are creating reusable libraries that require an IoC container in order to work, you should use the Common Service Locator instead. But don't even use that unless you absolutely require that your library be agnostic of the DI library used at the application tier; most of the implementation-specific containers/kernels offer much richer APIs that you'll miss out on if you nail yourself to the CSL.