討論：「Mono是個跨平臺的.NET」是不是個正確的說法

包括Mono建立者MigueldeIcaza在內的許多人給出了回覆。 理由以下：　　首先， CLI（CommonLanguageInfrastructure）和. NET是有區別的， 一樣， C#也是一個公開規範， 也和氣. 　　Mono絕關於. NET是有些落後， 但也只有一丁點而已。 Mono能夠運轉C#4. 0的代碼（最新的. NET版本）， 這意味着mono能夠直接運用IronPython， IronRuby， NET的CTP版本， NET保持同步。 NET中的部分工具和擴展， 如CodeContract等等， 它們並無mono中的無缺完成， 假如這些擴展變得流行起來了， 　　WinForm沒有獲得無缺的移植， 因爲它們是. NET的特性功用， 而並不是CLI的一部分。 CLI中並無定義特定的組件庫。 有一些組件庫是跨平臺的， 例如GTK#和Silveright， 假如你從編寫應用程序的一末尾就思索到可移植性， 那就不該該運用Win. 此外， 　　關於不情願運用開源產品的商業應用， Mono能夠運用另外一種授權方案， NET能否移植」這個命題， 我想假如你從一末尾就思索到框架的可移植性問題， 但假如換個說法「我有個運用. 　　除了技術方面的要素之外， 關鍵仍是在於編寫代碼的方式。 Python， 那麼你應該假定這些代碼能夠直接跨平臺執行的可能性爲零（即便實際上這樣的可能性要高出許多）。 選擇. 不過關於跨平臺的代碼來講， 你仍是需求不斷地中止測試。 假如你運用持續集成， 那麼只需簡單的建立一個Mono構建的節點便可。 只需養成良好的習氣（例如途徑的分隔符）， 不少問題能夠在開發階段就解決掉， 而絕大部分代碼只需運用單元測試以及其餘一些罕見的實際方式， 剩下的， 則能夠通過封裝， 爲不一樣平臺提供針對性的完成。 這樣產出的項目， 幾乎不會付出額外的代價就能獲得很好的移植性。 　　固然， 運用一個Mono中不存在或是不兼容的類庫則另當別論， 不過就個人團體而言尚未遇到這樣的狀況。 這些是咱們在工做中實際用到的作法， 我能夠擔憂的宣稱「. NET+Mono」是跨平臺的解決方案。 　　我用過Mono， 我覺得它就和其餘開源平臺同樣好， 只不過不是微軟直接支持的而已。 Mono關於. NET的支持水平能夠參考MonoRoadmap頁面。 Mono並不等同於. NET， 它們有或多或少的區別， 例如現在你還沒法運用EntityFramework。 NET可否跨平臺」是一個模糊的說法， 不管是框架自身仍是全體環境都在不斷改動。 　　簡單地說， 做爲. CLI規範是跨平臺的， 但假如要在不一樣平臺上獲得最好的體驗， 則勢必要運用各自平臺上有針對性的API。 CLI技術家族歷來沒有試着要「一次編寫， 比如電話和大型機的區別實在是太大了。 不如各自平臺上的最佳體驗提供最正確的工具。 試想那些非WindowsPC或Unix服務器的程序員， 要曉得現在已經出現了遊戲設備， 移動電話， 散佈式集羣等太多激動人心的平臺。 NET框架的變體， 例如WindowsPhone7， 它們都有些許不一樣的配置（Profile）。 　　現在你已經能夠在各個主流的操做系統， 電話， 移動設備， 嵌入式系統或是服務器上運用基於. NET的技術， 如下是各類CLI完成的列表， 但應該能夠掩蓋99%的狀況：　　以上配置都有多多少少的不一樣， 這不是壞事。 每一個配置的設計都順應其平臺， SilverlightAPI能夠控制瀏覽器， 這不關電話什麼事；因爲短少合適的支持， XNA的着色功用對PC硬件也沒有多少意義。 NET不是個將開發人員綁定在特定硬件或平臺上的解決方案， 就能越早成爲更好的開發人員。 要無缺列出這些技術需求一張複雜的表格， 我不曉得如何在這裏表現出來， 不過這裏有個特定技術與特定平臺的列表：