对于COM对象不再需要再在服务器上注册的这个功能我们是非常喜爱的。但是通过这种过程简化，我们也能也许会在不 经意间将一罐蠕虫病毒打开。这些恶梦躲藏在DLL背后的一个原因（就象我们愤恨的那样）即是它加强了版本的保密性。你再也不能够在你的服务器上运行 另外一个DLL版本，并且代码相当保密，这意味着，如果没有正确的开发工具和源代码，很难改变代码。 这个安全的机制，现在已经删掉了。你可以在你的服务器上运行任何你想运行的DLL版本，这些DLL可能会导致各种令人头痛的问题和安全方面的噩梦。 许多开发者喜欢COM对象的另一个很大便利之处是，你可以将你的商业逻辑打包，除了开发者之外，没人能看到它----对象是被编译过的，因此你的客户是看不到的。在新的框架里，你必须得用应用程序来分散源文件，因为NGWS一定会追踪源文件的轨迹。最终用户能够按他们的意愿浏览或者修改代码。当然，你也可以将 对象 编译，或者不给出源文件，但是随之而来的是，你会失去NGWS所提供的一些便利功能，这是得不偿失的。 你也要密切留意那些进入你文件的人可能使用的一些源控制之外的东西（例如：Visual Source Safe）。那么任一用户都会相当容易的进入或者修改你的 objects，那么去想想那些黑客们吧。 对于XML来说，这些问题同样适用。任何人都能轻而易举的黑了你。 适应性 肯定的是，通常任何一个全新的技术，在市场渗透都会花费一些时间。微软正在开始让ASP和IIS平台通过行业验证， 以便让其作为其它网络服务器之外可以供选择的平台 对于在其基本构架上的如此巨大的改变，是很难说服客户或者开发人员丢弃他们以前所使用的方法而来改用现有的方法。当然，随着时间的流逝，问题总是会被慢慢的解决，但事实上，ASP+要被市场接受，所面临的是一道障碍；即使慢慢的被采纳，寻找高品质解决方案和技术支持方面的问题也会接踵而来。事实上，ASP.net仍然是个alpha 技术，但在寻求支持方面，它又是如此幸运。 现存代码 当然，在将系统转换成 ASP.net之前，你得将你所有现存的代码重写一遍。你的那些旧的代码仍旧会在IIS内运作，但你仍然将使用传统的ASP框架（这不是件坏事）。当然，将一个庞大的web 应用程序移植到ASP.net中是一件非常痛苦的过程，特别是你已经有大量的解决方案或者说是COM对象。 ASP.NET代码编译 让我再重申一次:ASP.NET 代码现在被编译了.别紧张,这不是象你想的那样.你不需要创建文件,为了重新注册部件不得不stop 然后restart，现在不需要这样了，你只需照往常一样书写代码,仍然从早期捆绑中受益，系统会及时进行编译。
