>you should always know at least one level below the framework you are using
I run into this problem whenever I'm interviewing for devs on my team. As a java shop, we usually get people who come in and claim to be proficient in Spring, but when I start asking them questions about the underlying technologies they blank.
My favorite weed-out question when I'm worried someone is too tied to a framework (especially when its one that isn't actively in use on a project) is to ask them to give me some examples of the limitations of it. To me, being able to recognize the things your favorite framework is not able to solve effectively is the best indicator that you aren't using it as a crutch.
I can’t think of any limitations of ASP.Net MVC with all of its extensibility and I have a fairly good understanding of both the frameworks and the underlying technology (HTTP). I’m not sure I could answer that question.
Now on the other end AWS CloudFormation for infrastructure as code, I could go on for days about its limitations.
1) It's a web framework. So, not suitable for command line tools, desktop GUIs or persistent message queue workers. But you can do all of that in other kinds of C# .NET app.
2) However, .NET is a Garbage Collected language and should not your first choice for e.g. a real-time device driver or OS kernel.
Mathematically, you're not wrong. You can draw a line around the set of things that any particular software platform is good for, and the area outside of it will be infinite.
But people do try to do some of those things that I listed, using ASP.NET.
I was thinking you meant in the context of creating a web application but yes. You should never use ASP.Net to run any long running process even if it is kicked off via a REST call. You should use out of process web workers or some other type of queuing mechanism.
I run into this problem whenever I'm interviewing for devs on my team. As a java shop, we usually get people who come in and claim to be proficient in Spring, but when I start asking them questions about the underlying technologies they blank.
My favorite weed-out question when I'm worried someone is too tied to a framework (especially when its one that isn't actively in use on a project) is to ask them to give me some examples of the limitations of it. To me, being able to recognize the things your favorite framework is not able to solve effectively is the best indicator that you aren't using it as a crutch.