Even with .net framework 4.x you need to bring the framework with you, if you want to use the newest frameworks, as your customers might not have the most current version installed.
The point as formulated still stands though. You don't have to because you can always guarantee that your end users will have a Win32 runtima and a .NET runtime.
There is a choice, and it's between using a later framework, and relying on the OS one.
The choice being stuck with what a specific Windows version has available and using OS APIs directly instead of C ones, e.g. ZeroMemory() instead of memset(), as the C runtime library isn't part of the OS.
Yes, I was only talking about Win32 and .NET, which is always bundled in windows (Obviously newer versions of the OS may have newer versions of them).
How C libraries work has never been a problem I have encountered (I do deploy C++ libraries with apps though, and the tendency to move to "all apps deploy a full copy of whatever runtimes they need" is a much better situation for all 3 parties involved (developers, users and hackers...).
I get the point of memset (although that particular example I believe is now an intrinsic).
