You usually are using DI, so you'll have an interface that you need to resolve and do stuff.
How is alive going to deal with that?
Alive isn't performing static analysis and guessing what your code is doing, it's compiling and running it while showing you the results. So as long as you have unit tests covering a piece of code, we can run those tests and show you what that piece of code does.
And here's another on using tests with Alive: https://www.youtube.com/watch?v=qJgMqTTKPBg&feature=youtu.be
I thought that was all a bit of a fad like factories. Lots of extra code for little benefit. Especially in a statically typed language like C# where it gets rid of so many of the benefits of using it as a language.
I look at DI, or really the dependency inversion pattern, as a guard that encourages better/more maintainable code. Can you write good code without it, sure, and you can write bad code with it, but it's much more likely that code written with it is easier to trace and maintain. Not to mention much easier to test.
The configuration based, hot-swapping of dependencies...that I've never seen much need for even in larger projects.
I use it mostly for unit testing.
I've found it immensely useful to not go through the rigamarole of newing up a ton of objects manually in my web controllers and queue/batch processing frameworks. Just choose your composition roots properly and you can easily add new endpoints/jobs/event processors without all the worry of resolving all the dependencies manually.
It also allows you to reduce footprints (setting non-stateful code/configuration objects as singletons), transparently cache and instrument(dynamic proxies, or application specific caching/logging wrappers), and other similar application-level concerns without it infecting consuming code or otherwise independent modules.
I myself and my team use AutoFac right now, but who knows what it could be in 1-2 years...