Thanks for your kind reply.
Regarding the use of CLR integration within SQL Server: a highly competent database developer such as yourself (I've visited your website - impressive stuff!), who understands both tool sets extremely well, would hardly ever make errors which might adversely affect SQL Server performance and security.
However, I've seen less-skilled individuals compromise both. (I've observed this tends to be an issue more in smaller shops, where the talent pool may not run as deep, than in larger ones. 'Small shop DBAs' are not necessarily experienced database developers.)
These two problems seem to be the most contributory:
1. The DBAs I've observed are simply much more familiar with T-SQL than with .Net. That doesn't mean they shouldn't learn .Net, nor that they should refrain from using CLR integration; only that there is currently a much higher level of competence with T-SQL.
2. 'Best practices' are not always followed. I've seen .Net code employed when it would have been much more appropriate to use T-SQL constructs for the particular job at hand. Microsoft discusses part of this issue
- please see particularly the section 'CLR and Its Alternatives'.
These problems can be remedied through more training and experience; but in the meantime, they make the deployment and maintenance of .Net code in SQL Server somewhat problematic.
Re .Net, Silverlight, HTML5 and JS: don't shoot the messenger! I'm just relaying some of the scuttlebutt that's out there right now. Hopefully we should all know more, once Microsoft completely explains its plans for its software development frameworks, supposedly come September. I agree with you that Silverlight particularly will still have a future. Our GIS group uses it extensively with ESRI-based applications, and so long as ESRI supports Silverlight, we'll continue using it.