Quite a few of the replies are practical, but unfortunately reality isn't always practical. Instead we often use technology for signaling, and the truth remains

Quite a few of the replies are practical, but unfortunately reality isn't always practical. Instead we often use technology for signaling, and the truth remains that the Microsoft stack (even if you talk up open source equivalents like mono) is an anti-quality signal. This is not judgmental (I have used and abused the MS stack for years), but is observational. And that tendency is often based upon experience -- the bulk of .NET programmers are enterprise inhouse developers usually building dated, poor quality solutions. This hits hiring as well. Someone mentioned the quantity of .NET programmers, and while this is true the quality is extremely, extremely poor on average. Having had to hire .NET programmers, the best success we have had, result wise, is to hire !.NET programmers (e.g. the hiring process started being about abstract problems that could be solved with anything, etc) and let them loose with C#/etc. If we limited ourselves to the .NET skillset we got tonnes of applications, almost all of which were terrible.