从一开始，.NET栈就对不受管理的库提供了一流的支持。通过使用P/Invoke，开发者可以访问大多数的Win32 API，同时还能获得COM支持以访问大量的应用和第三方库。随着近期动态语言运行时的不断发展，使用Python、Ruby及JavaScript编写的脚本也加入进来了。

但.NET开发者应该这样做么？Clint Hill说：不。

这项工作很棒而且工具也在不断改进着。.NET来了，这真令人感到兴奋。但6年过去了，兴奋的感觉却在不断消褪。整个文化开始变得有点疯狂了。这种文化的一个原则（从广义上来说，我使用了原则）是你所用的所有组件都必须从.NET继承下来。也就是说如果你需要一个Web控件库，那么它必须是个.NET C#库，因为你正使用它来构建项目。如果这个库不是免费的，或者是花钱也买不到，那你只能自己去构建了。
这会导致一些问题，往小里说会导致项目开发速度变慢以致延期。往大里说会导致开发者不再相信其他的技术了，无论这些技术是如何完美的解决问题的。现在我对这种情况感到非常失望。
Clint将这些问题一股脑儿的回复给了畅销书作者Jeff Atwood所发布的一篇博文。Jeff与知名作者Joel Spolsky现在正从事于一个名为Stack Overflow的论坛。当他们想清理其站点的HTML时，Jeff对现有的库都不太满意。他的原因是：因为他们不是用.NET编写的。

我花费了整整一周的时间为Stack Overflow构建了一套HTML清理函数，我会对此感到后悔么？肯定会的。在.NET生态圈外有大量的清理解决方案，但针对C#或VB.NET的却少之又少。我已经将核心代码贡献给社区了，所以未来的.NET冒险家们可以将我们的代码作为其旅途上的路标了。他们可以从我们编写的简单、常规的代码中学习，然后将其继续用在Stack Overflow上。
Dare Obasanjo解释了通常情况下这为什么不是一个好办法。

Jeff尝试解决的问题是允许HTML标签的部分子集而排除其他的标签以避免跨站点脚本（XSS）攻击。Jeff的解决方案的问题（社区中的很多人包括Simon Willison都已经指出了）在于他使用了正则表达式来过滤HTML输入，这种方式会假设你所得到的HTML都是格式良好的。而这时问题就来了，正如很多开发者所指出的那样，你不得不考虑由于很多现代的Web浏览器自由的HTML解析方式所产生的不规则HTML。这样如果你不想将貌似安全实则有风险的HTML存储起来，那你就必须对常用浏览器所处理的每个HTML进行反向工程。这样，要想使用这种方法，Jeff真的应该考虑使用功能更加完善的HTML解析器，如SgmlReader或者Beautiful Soup而不是正则表达式。
这场争论不仅仅只是关于HTML清理，它还触及到了.NET文化的核心。对于.NET开发者来说，在你每天的工作中使用非.NET库好么？