[ducharmdev]

Yup, all one repo fortunately. The majority of changes were in 3 class library projects, each of which is referenced by web portal, API, and nightly jobs projects. I'd imagine it could be quite painful if scattered in various repos!

[shoo]

i've sometimes enjoyed this kind of work in the past, provided there's good automated test coverage / static analysis from compiler & tooling to lean on. After the initial experimentation to decide on the new structure and confirm it is going to work, put on some good music and grind away at it.

[ducharmdev]

Haha yep, that just about describes how it went for me. No way would I do all that without automated testing too - the immediate feedback is crucial for broad changes like this, that way if you do find you've made a wrong judgment in your approach, you find out immediately and correct your course.

One thing specific to .Net DI that made it easier was an extension method provided by our architecture team that does a "warmup" of all dependencies registered in your service collection. In practice all this means is, on app startup, it attempts to instantiate every registered service; if a dependency is missing, you'll get an exception for the service that failed to be created with the dep it failed on. Very helpful for chasing down issues related to missing service registrations!