對于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，現在不需要這樣了，你只需照往常一樣書寫代碼,仍然從早期捆綁中受益，系統會及時進行編譯。