有沒有人聽說過任何關於微軟[不]支持未來版本的Windows的COM？組件對象模型的未來
我認爲微軟的工程師們會堅持使用它（即使他們更願意只開發和支持.NET框架），只是因爲他們巨大的客戶羣會產生巨大的反彈。在野外肯定有數十億行基於COM的東西。我知道我是而不是期待被推入大規模遷移，只是因爲一些聰明的褲子過度實現建築宇航員必須證明他是最偉大的......（sheesh，爲什麼他們不接受拳擊？）。
我懷疑我只是偏執狂，但任何人都可以提供任何authorative鏈接（谷歌找不到多少）？理想情況下，微軟的白皮書說：「COM在維也納停留，否則！」會很大地解決我的神經。
那麼他們稱之爲.NET的原因是因爲COM3被當作串口名稱。 .NET 是新的COM。從.Net Common Language Runtime Unleashed：
名稱從COM3更改爲COR到COM + 2.0 ...到NGWS，最後到.NET。
的原因主要組件名爲mscorlib程序是，它代表着微軟公共對象運行時庫。
COM仍然是THE進程間通信技術。看看你可以從另一個應用程序中控制Word，Excel等的方式。沒有辦法.net可以取代這個。
.Net CLR也可以作爲COM DLL來實現，如果我沒有弄錯的話......這只是我們'在比COM更高的抽象層次上......在演化後的下一個階段 – Gishu 2008-09-25 15:12:46
關於Office的觀點是重點。只要人們使用COM來自動化Office，它將受到操作系統的支持。 – 2008-09-25 15:21:12
由於存在大量傳統的基於COM的代碼，因此無法立即看到COM消失。出於同樣的原因，我期望看到Win32在可預見的未來中徘徊。沒有人關心Windows，就像平臺一樣，他們關心他們的應用軟件。
出於同樣的原因，在S/360，S/370，S/390，zSeries和C/unix上的COBOL仍然是非常廣泛使用的平臺。
沒有任何官方聲明稱COM支持將從未來版本的Windows中刪除。它廣泛用於OS內部。從零開始徹底重寫操作系統（我很快就無法想象），可以肯定的是COM會在那裏停留一段時間。
COM和.Net服務於不同的需求。只要有本地代碼，就需要二進制組件化標準，即COM。即使操作系統是從頭開始重寫的（它不會，也不應該），它主要是基於性能和版本等原因的本地代碼。你很快就需要發明像COM一樣的東西，爲什麼不保留那些經過測試和工作的東西呢？
所以總結：
COM會留下來，因爲：1。 它從根本上工作 2.處理進程間通信，從機器間的通信截然不同。 3. .NET很大程度上繼承了COM，但並不是所有東西。即使微軟自己仍然依靠它。
我認爲現在生產系統中仍然有超過百萬行FORTRAN和COBOL ...因爲它們從根本上起作用。
謝謝大家的回答... MODS，隨時清理這個會話回覆，但是（恕我直言）這個網站會很好地讓海報公開感謝那些花時間回覆的人。
乾杯所有。基思。
我知道很容易認爲微軟的世界從現在開始只是.NET，這要感謝他們的營銷部門所做的出色工作，但微軟總是支持他們的舊東西，他們沒有選擇。
看看MFC，他們已經發布了新的包，並且RibbonBar只能在MFC上工作（因爲辦公室是在其中開發的）。當然，隨着時間的推移，他們將開始編寫越來越多的.NET代碼，並且越來越少的COM工具，但他們仍然會支持它。
Visual Studio中的COM開發功能將保留在原來的位置，這是您知道他們不再希望我們使用它的時間。
我從Visual Studio項目經理那裏看到一個blog entry，他說他們收到了很多開發者關於最近關注C＃的投訴。他同意並表示Visual Studio的下一個版本將主要集中在非託管C++開發上。
Common Object Runtime！=組件對象模型...但是，我仍然是你的觀點，thanx ;-) – corlettk 2008-09-25 14:35:51