我在.net中注意到它極易反向工程exe。這是因爲.net可執行文件只是.net引擎的指令代碼，因此.net是一種解釋型語言？從來沒有執行過本地？.net是否提供真正的可執行文件？
我必須承認，我從來沒有與.NET代碼的任何性能問題，所以這就是爲什麼我在懷疑我。
難道有人請給我解釋一下嗎？
感謝迄今答案，沒有人知道爲什麼微軟決定創建要求框架的這個方法，如果我沒有記錯的VB6的代碼的天編譯爲本地。是否有很好的理由.net代碼現在必須通過解釋器運行>
.Net可執行文件包含MSIL（微軟中間語言）字節碼，類似於Java字節碼。它們不是原生的Intel32代碼，不能在沒有安裝.Net框架的情況下運行。除了MSIL之外，還包含大量的元數據。您可以使用Ildasm或Reflector查看.Net可執行文件。
從技術上講，他們沒有解釋，但JIT（Just-In-Time）編譯成機器碼。有一種方法可以將它們編譯爲本地代碼，NGen.exe實用程序。有時，JIT代碼可以比NGen更快，因爲它可以執行運行時分析。
它們是字節碼。理論上字節碼可以比本機碼快，所以不要把性能考慮進去。
本機代碼只是CPU理解的字節代碼。 – 2009-10-09 08:33:27
原生代碼必須編譯爲特定的體系結構，這通常是x86上的最低公分母。字節代碼可以被JIT'ED到當前支持的任何機器，允許您利用CPU支持的更高級功能。 – 2017-05-03 15:29:34
.NET exes與其他可執行文件一樣是PE文件，但它們包含額外的部分以包含IL。看看this thread的最後一篇文章，看看更多細節。
該.exe文件包含代表IL指令的字節碼。當您啓動應用程序時，JIT編譯器會將其編譯爲專門爲您的處理器創建的本機代碼。
因此，雖然可執行文件不包含本機代碼，但執行的是本機代碼。由於JIT編譯器可以針對特定處理器優化代碼，因此它有可能比生成的任何處理器上運行的本機代碼更快。
這是否意味着每次啓動一個.net應用程序時，它都會被編譯爲本機？如果是，它非常快...... – 2009-10-09 08:39:23
不，已編譯的程序集被緩存，甚至可以使用稱爲ngen.exe的工具將程序集預編譯爲本機代碼。 – 2009-10-09 08:42:32
如果您使用ngen，這是否意味着您的IP更安全？並免除反映？ – 2009-10-09 08:45:48
不，它們不是正常的可執行文件。它們包含CLI標準中定義的元數據和CIL（通用中間語言）指令（請參閱ECMA-335-http://www.ecma-international.org/publications/standards/Ecma-335.htm）。
至於CIL被解釋：.NET的大部分verions不interprete的代碼，但JIT（剛剛在時間）編譯。這意味着，當應用程序運行時第一次使用一段代碼時，代碼將被編譯爲本機代碼，並從此使用此本機代碼。但是這實際上是一個實現細節，例如就我所知的純粹解釋的Micro框架而言。
至於問題的編輯：
的原因是，通過在元數據和一個共同的instrcution組代碼的常見表現是，它會更容易實現互操作不同的語言說方式之間。
因爲所有的語言講同樣的，常見的「低層次」的幕後語言，它們能夠無縫地相互集成。
.NET不被解釋。當代碼實際執行時，它是一個由MSIL編譯的本地代碼，這要歸功於JIT。該可執行文件包含生成本機代碼所需的MSIL指令。
當您第一次加載.Net程序集時，字節代碼（MSIL）被編譯爲本地機器代碼（Just In Time編譯），並且從該點開始，它作爲本機彙編程序運行。所以.Net程序集是而不是的解釋，但是當它們第一次出現時，你確實會得到一個小的性能提升。然而，jitting的優勢在於，JIT編譯器可以優化彙編運行所用的體系結構（CPU指令集等）的彙編程序，而傳統的編譯時（如C++）則不一定如此。
如果您願意，可以使用ngen預編譯.Net程序集，避免JIT開銷。
是的，他們不是「真正的」。你要創建的exes將被MSIL編碼。當你運行你的一個前置代碼時，代碼將被CLR（公共語言運行時）轉換爲機器代碼。
MSIL代碼可以很容易地反編譯。您可以使用.NET Reflector，它是免費的。您也可以從C＃代碼的轉換到VB.NET或C++等，當你編譯你的EXE ...
，你也可以嘗試Xenocode Postbuild obfuscator它使你的EXE Native32和混淆，.net反射將無法編譯你如果你使用這個混淆器的話。但是，它使得你的exes有點大：）...
+1看起來很棒 – 2009-10-09 08:47:20
問題應該是什麼是「真實」的可執行文件。
可執行的.NET程序集存儲在Portable Executable（PE）格式中，該格式是用於Windows中可執行文件的文件格式之一。
這是一個封裝格式，告訴操作系統所有必要的信息來執行包含的代碼。
從這個意義上說，.NET可執行文件是完全「真實」的前綴。
然而，對於.NET程序集的PE格式已經extended：
Microsoft的.NET Framework已經 擴展了功能 支持公共語言運行時 的PE格式。其中增加了一個CLR 標題和CLR數據部分。在 加載二進制文件時，OS加載程序通過PE/COFF IMPORT表中的引用 向CLR執行 執行。然後，CLR 加載CLR標題和數據部分。
的CLR數據部分包含兩個 重要段：元數據和 中間語言（IL）代碼：
元數據包含有關該組件的信息，包括 集清單。的清單 詳細描述 包括唯一標識（經由 散列，版本號等），上 導出組件的數據，廣泛 類型信息（由公共 類型系統（CTS）的支持），外部 組裝參考文件以及程序集中的文件列表> 。CLR 環境大量使用 元數據。
中間語言（IL）代碼被抽象，語言無關 代碼滿足.NET CLR的 公共中間語言（CIL） 要求。術語「中間」 是指IL代碼的性質是與跨語言和跨平臺的 兼容的。這種中間語言 語言類似於Java字節碼， 允許平臺和語言 支持常見的.NET CLR。 IL 支持面向對象編程 （多態性，繼承，抽象 類型等），異常，事件和各種數據結構。 IL代碼爲 ，由CLR組裝到.NET PE中執行 。
作爲freetime- mono -developer我傾向於回答你的問題的最後一部分（是否有一個很好的理由有通過翻譯立即運行.NET代碼？）： 是：可移植性
但他們仍然像其他exes一樣的PE文件。 – 2009-10-09 08:35:42
DBKK，如果我理解你，.net可執行文件被解釋了嗎？但是這種解釋是非常有效的，因爲.net可執行文件已經被編譯爲字節碼，當你保存它時？ – 2009-10-09 08:36:17
它沒有被解釋，它是即時編譯的，因此在執行之後會有輕微的性能下降，因爲字節代碼被編譯爲本機。一旦完成，就沒有本質的性能差異。 – 2009-10-09 08:39:45