This was going to be my question. For your own classes and services, nothing is stopping you. You can new up classes without DI all day long. ASP.NET does layer on it's things using DI, but it's boilerplate built into templates. For example, OOB you may use the built in UserManager to authenticate users and store their info in a db. If you want to customize that and NOT use the built-in, you may have 10-20 lines to write in Startup.cs to inject a different UserManager or configure the built-in one differently. I've never felt it was massive or wasted my time vs Node/express work I've done.

Because if you don't tow the line, you'd be accused of heresy and blasphemy from the community and/or coworkers - I'm only partially joking.

"toe the line"

“ what does stop you from simply not using DI in .NET?”

Duh! Then how’d you wire up interfaces with implementation aka constructor injection?

Like so: `ISomething something = new Something();`

Construction injection is a type of DI, and it's optional, you don't have to use it.

edit: for clarity

OMG! I was wondering you might be proposing this. You should not be using "new" keyword anywhere in your code. If you have hard coded implementations like that in your code then how will you mock them in unit tests? I hope you'll not reply-with saying "don't write unit tests".

"OMG! I was wondering you might be proposing this. You should not be using "new" keyword anywhere in your code"

That sounds like dogmatism, and I'm going to take a special note of the emotionally charged language you're using here; it's symptom of some of the underlying issues I see in our industry (more to be said on this).

That said, I do agree with the sentiment in general, but you can (and sometimes should) use the `new` keyword in your code, especially when writing tests. In some cases, it makes testing so much easier and helps with the maintainability.

"I hope you'll not reply-with saying "don't write unit tests"

After 2 decades in this profession, the only think I'm sure of is there is no "silver bullet". Of course, as a general rule, it's a good idea to have a test coverage of your codebase but sometimes it's not valuable and not worth adding it. So it's a "it depends" from me!

I am a big fan of DI, but you can often get a lot of useful unit testing done when you try and keep I/O mostly seperate from the rest of the code. If you have ever programmed in Haskell you will know what I mean.