.NET
Colin Fahey
1. 定义.NET
任期“.NET”指下列收集技术：
（ 1 ） Framework Class Library (FCL)
（ 2 ） Intermediate Language (IL)
（ 3 ） Common Language Runtime (CLR)
1.1 Framework Class Library (FCL)
该Framework Class Library (FCL)是一个广泛的班，以支持：
*容器(Array, String, List, ...)
*多线程（线程，线程池）
*网络（套接字，协议，客户端，服务器）
*文件操作
*数据流
*解析（正则表达式， XML处理）
*数学行动
*异常处理
*语言功能（反思，堆栈跟踪，动态代码）
该Framework Class Library (FCL)是实施了很多不同的平台( Windows, Linux, MacOS, ... ) 。
因此，一个单一的计划使用Framework Class Library (FCL)可以发展无显着的知识之间的分歧目标平台。
该Framework Class Library (FCL)包含有用的模式的基本概念计算机科学（如“线” ， “插座” ， “流”等） 。
在某种意义上， Framework Class Library (FCL)给每个支持的操作系统一个现代化，高层次的，一致的编程接口。
该Framework Class Library (FCL)是其中一个最先进，全面，统一设计，证据确凿的收藏品的功能和数据类型提供给程序员。
不幸的是，以下多媒体方面是不是部分的Framework Class Library (FCL) ：录音，音频播放，视频录制，视频播放，三维渲染，操纵杆投入，设备控制( CD/DVD, ... )等。
Microsoft有一个.NET版本的DirectX图书馆为他们Windows作业系统。
有C#包装OpenGL ， OpenAL ， GLUT ， SDL等，但，这是不太方便，有这样的多媒体功能被包括在核心Framework Class Library (FCL) ，并包括在最终用户“的运行时”库。
其中一个问题，发展中国家的程序使用，特别是图书馆的是，打算订定的最终用户将需要支持选定的图书馆。
如果没有方便的下载和安装必要的图书馆，最终用户可能会选择不使用的程序，要求这些图书馆。
最终用户也可能不愿意等待一个图书馆下载从线上的位置。
如果某个程序的开发需要一个最终用户寻找，购买和安装的图书馆，所有的援助，从某个特定程序，然后最终用户可能会选择不使用该程序。
例如，许多开放源代码项目，要求最终用户寻找，下载和安装，许多不同的图书馆从其他开放源代码项目（例如： openssl ， zlib ， libpng ， libjpg ， glut ， ...),这是时间消费性，复杂性，令人沮丧，并可能导致最终用户的选择，以寻求其他的程序或产品。
该“Windows Update”服务，显然有利于部署版本1.1的.NET运行时间图书馆Windows用户。
这些运行时间图书馆包括与Windows XP作业系统。
因此，创造Windows程序需要.NET 1.1似乎是完全合理的。
此外，运行时间图书馆Microsoft's实现的.NET Framework Class Library (FCL)可以自由地重新分配，使开发人员可以供应这些图书馆向最终用户谁不已经有图书馆。
该Windows Vista作业系统的船舶与.NET 3.0运行时间图书馆（组合的.NET Framework Class Libraries和几个新的图书馆，如“Windows Presentation Foundation” (WPF) ） 。
因此，部署.NET 2.0和.NET 3.0节目Windows Vista并不要求安装工人为.NET运行时间图书馆。
1.2 Intermediate Language (IL)
该Intermediate Language (IL)是一个很小的一套简单，处理器的独立，操作系统独立的指示，足以完全表达数据的结构与功能很多不同的高层次的编程语言( C++, C#, F#, Visual Basic, Java, Ocaml, ... ) 。
源代码的书面在一个高层次的语言可以编译下降至一个相应的“Intermediate Language”形式。
代码在一“Intermediate Language”形式，可以轻松地结合起来，与其他代码在一“Intermediate Language”形式。
一个计算机程序（也称为“软件” ） ，可以包括源代码的书面在几个不同的高层次的语言（例如， C# ， C++和Visual Basic ） 。
所有的源代码可以编译（改建）一“Intermediate Language”格式，让容易结合起来，与其他编译代码。
计划在1 “Intermediate Language”形式通常是转换为机器具体的指示（例如， CPU指示）非常前不久，执行（例如， “Just-In-Time” (JIT)转换IL ，以CPU指示） 。
但计划也可能被处死，在一个Virtual Machine (VM)旨在解释Intermediate Language (IL)指示。
编写的代码在各种高层次的语文( C#, F#, Ocaml, C++, Visual Basic, ... ) ，可编译Intermediate Language (IL)形式使用适当的编译器对任何支持的平台( Windows, Linux, MacOS X, ... ) ，和由此产生的文件，与嵌入式Intermediate Language (IL)代码，是独立于平台，并可以执行任何平台上有一执行该.NET Common Language Runtime (CLR) 。
该Intermediate Language (IL)代码所产生的编译器，基本上是独立于哪一种平台上编译被执行死刑。
1.3 Common Language Runtime (CLR)
该Common Language Runtime (CLR)是机制，负责执行的代码提交上来，在Intermediate Language (IL)形式。
该Common Language Runtime (CLR)提供各种服务。
该Common Language Runtime (CLR)可转换Intermediate Language (IL)代码指示是本土向平台（例如， CPU指示） 。
转换从Intermediate Language (IL)平台特定（例如， CPU具体）的指示，可能发生在任何提前执行（即，一“Ahead-Of-Time” (AOT)转换） ，或可能出现的逐步，作为计划执行（即， “Just-In-Time” (JIT)转换） 。
该Just-In-Time (JIT)转换可以使用不断变化的统计程序执行动态优化转换代码（例如：确定经常使用的循环和分支，和优化他们根据观察到的行为（即本身，取决于当前的数据和事件） ） 。
该Common Language Runtime (CLR)管理分配内存就代表该程序。
因此， CLR确保该计划不会未能获得分配内存，而参考这样的记忆仍然存在，并确保内存分配的取消，以及记忆体提供了再次用于将来的分配后，计划作主所有的提述，这种分配。
该Common Language Runtime (CLR)侦测时，该程序已不再提及内存分配，以及内存分配是标示为deallocation 。
该Common Language Runtime (CLR)使用任何一个不同的“垃圾收集”算法（例如： “mark-and-sweep” ） ，以确定和填海的内存块不再进入一个程序。
该Common Language Runtime (CLR)处理程序例外。
该Common Language Runtime (CLR)执行安全政策。
该Common Language Runtime (CLR)使用“P/Invoke”机制，以负载平台的具体图书馆和引用（呼叫）功能，这些图书馆。
2. .NET ( FCL, IL, CLR )实现由Microsoft
2.1 导言
该.NET范式( FCL, IL, CLR )已实施了由Microsoft 。
最新的版本， “3.0” ，被释放在2006.10 。
.NET 3.0组成的.NET 2.0 Framework Class Libraries和几个新的图书馆，如“Windows Presentation Foundation” (WPF)与“Silverlight” （原WPF/E ，以前Sparkle ， ... ）的浏览器插件Firefox和Internet Explorer 。
Microsoft划分.NET 2.0软件在两个不同的软件包：
（ 1 ） .NET Framework Version 2.0 Redistributable Package
该可再发行组件包是所要求的最终用户来执行程式建成为.NET范式。这个方案也必须安装由发展商之前，必须先安装和使用.NET Software Development Kit (SDK)下文提到的。
（ 2 ） .NET Framework Version 2.0 Software Development Kit
软件开发工具包(SDK)是所需要的开发编译C#源代码Intermediate Language (IL)程式档案。
这个套件包含各种开发工具和文件。
2.2 .NET Framework Version 2.0 Redistributable Package
该可再发行组件包是所要求的最终用户来执行程式建成为.NET范式。
这个方案也必须安装由发展商之前，必须先安装和使用.NET Software Development Kit (SDK)下文提到的。
以下的网际网路网页上，主要是.NET下载网页：
一节名为“.NET Framework Version 2.0 Redistributable Package”有联系的三个硬件平台： “Download x86 version” ， “Download x64 version” ， “Download IA64 version” 。
举例来说，下列连结“Download x86 version” ，导致1页，题为“Microsoft .NET Framework Version 2.0 Redistributable Package (x86)”
（档案名称： dotnetfx.exe ;版本： RC1 ;发布日期： 3/22/2006 ;语言：简体中文;下载大小： 22.4 MB ）
本地缓存的版本（只以供参考;潜在过时） ：
（档案名称已改为在这里从原来的档案名称， “dotnetfx.exe” ，以避免混淆，它与1.1 Installer的版本也命名为“dotnetfx.exe” ） 。
2.3 .NET Framework Version 2.0 Software Development Kit (SDK)
软件开发工具包(SDK)是所需要的开发编译C#源代码Intermediate Language (IL)程式档案。
这个套件包含各种开发工具和文件。
以下的网际网路网页上，主要是.NET下载网页：
一节名为“.NET Framework Version 2.0 Software Development Kit”有联系的三个硬件平台： “Download x86 version” ， “Download x64 version” ， “Download IA64 version” 。
举例来说，下列连结“Download x86 version” ，导致1页，题为“.NET Framework 2.0 Software Development Kit (SDK) (x86)”
（档案名称： setup.exe ;版本： 2.0 ;发布日期： 11/7/2005 ;语言：简体中文;下载大小： 354.0 MB ）
本地缓存的版本（只以供参考;潜在过时） ：
（档案名称已改为在这里从原来的档案名称， “setup.exe” ，以避免混淆，它与所有其他安装文件名为“setup.exe” ） 。
3. Microsoft Visual C# ： 1 Integrated Development Environment (IDE)计划
3.1 导言
1 Integrated Development Environment (IDE)程序让开发人员要编辑的源代码和执行各种工具（例如：编译器，调试器， … … ）的背景下一个单一的，统一计划，充满有用的视觉迹象显示和控制。
“Microsoft Visual C# 2005 Express Edition”是一个无成本（没有支付所需的） IDE可供下载从Microsoft 。
对于非数据库的开发，这是几乎是不可能的区分，这没有成本的产品来自零售业，对口， “Microsoft Visual C# 2005” 。
我经常使用这两种产品，专业和recreationally ，我还没有看到任何实际的差异产品。
3.2 官方联系
互联网网站的主要页：
网页关于“Visual C# Express Edition” ：
点击“Download Now”上的按钮页的右侧选择下载选项。
（一种方法是推出一个安装程序，将下载文件从Microsoft在每个安装。
第二种方法是下载一个充分CD-ROM “ISO”的形象，这使得未来的离线安装。
该ISO形象， “VCS.iso” （ 451,837,952字节; CRC 55884F2C ）对于32位元的x86英语，可能会被烧死的一CD-ROM使用“Nero 7 Ultra” ，例如。 ）
4. .NET ( FCL, IL, CLR )实施由Mono Project
4.1 导言
该.NET范式( FCL, IL, CLR )已实施了与会者在一组称为该Mono Project 。
4.2 官方联系
项目选址：
软件下载页：
4.3 本地缓存版本
本地缓存版本的安装程序（只以供参考;潜在过时） ：
4.4 .NET 2.0发展与Mono
该“mcs”编译器，和文件，截至11月2006 ，大多涉及到C# 1.0和FCL 1.1 。
不过， “mcs”编译器能够编译C# 2.0代码不包含仿制或通用型功能，但限制API ，以1.0 。
这样做充分C# 2.0发展，与FCL 2.0图书馆，使用“gmcs”编译器。
请参阅下列网页上Mono网站：
5. SharpDevelop ：开放源代码Integrated Development Environment (IDE)计划
5.1 导言
1 Integrated Development Environment (IDE)计划允许开发人员要编辑的源代码和执行各种工具（例如：编译器，调试器， … … ）的背景下一个单一的，统一计划，充满有用的视觉迹象显示和控制。
SharpDevelop是一个很好的，开放源代码IDE计划C# / .NET发展。
这IDE紧密合作，类似于Microsoft Visual C# IDE ，并在某些方面， SharpDevelop IDE有所改善后， Microsoft产品。
不过， Microsoft Visual C#有一些功能（例如：调试）表示， SharpDevelop程序没有（在当时的这个写作） 。
5.2 官方联系
简单的互联网网站主要页：
网页关于“The Open Source Development Environment for .NET” ：
下载网页，其中有详细介绍1.1和2.0版本的SharpDevelop ：
5.3 本地缓存版本
本地缓存版本的安装程序（只以供参考;潜在过时） ：
6. 有用的C# / .NET / IL工具
6.1 SciTech Software “.NET Memory Profiler”
这Profiler中显示内存分配，和其他的资源分配，即编译.NET程序或大会，而使得执行。
实时图形，使一个人看到，在详细，如何行动的程序（如行动所引发的用户输入或其他事件）影响内存分配和垃圾收集。
实时时间表上市的看法，使一个人要了解详情，内存分配。
这Profiler的即时，并大幅透露，浪费内存使用在一个真实的时间Direct3D计划，我发展。
的格局，向上斜道和突然下降（由于“垃圾收集” ）在记忆体使用量的图匹配完全与定期，极简短的停顿，在三维图形我的计划。
的Profiler使我发现，频繁的分配临时对象是积累了大量的存储空间，触发垃圾收集频繁，并采取足够的时间，每个垃圾收集，造成数绘图期不容错过。
的Profiler的实时时间分配表的对象类型揭示了类型的对象，其中最消耗内存，并分配消耗内存在最高速率（每秒字节数） ，并分配了最高的处理率。
研究实时图形和实时时间表，让我把重点放在研究以何种方式的某些数据类型被用来在我的代码。
修改代码来避免频繁的分配临时对象可以大大减少的整体比率内存分配和处置，因此可以减少频率垃圾收集触发。
（我相信“Bytes/sec”是一个非常揭示了统计的实时时间内存使用中，除了“Live instances” 。
）看到所有这些正在更新很快，在一个表格式，并能够选择如何行分拣，和不断变化的分拣参数在任何时间，使学习的经验，一个真实的时间，程序非常具有吸引力和翔实。
内存分配的反应，用户交互与正在运行的程序，可以研究，并测试能迅速适应的反馈意见，以缩小最有趣的方面。
（举例来说， 2006 July版本有下列属性：版本2.6.89 ; 4.3 MB ; USA $127.00 ;下载14天的限制版本，在没有任何成本，进行评估。 ）
6.2 FxCop ： .NET代码分析仪/影评
FxCop分析汇编.NET程式（或汇编大会） ，并生成一份报告，上市可能出现的问题，与原来的源代码。
可能的性能问题和安全问题是确定的。
可能的编码公约的行为确定。
FxCop并不需要访问原始的源代码来执行分析。
只有编译.NET计划（其中包含IL ）是必需的。
尽管如此， FxCop报告提供的超连结，以具体的行号在原来的源代码。
如果Microsoft Visual C# 2005 IDE是积极的，点击超连结，在FxCop报告将导致IDE ，以经向有关的源文件和行号。
FxCop已在我看来，一个颇为尴尬的方式结合Microsoft Visual C# 2005 IDE 。
不过，一旦它成立， FxCop产生了一个很有趣的和潜在的-有价值的报告。
该报告书载录详细的意见，就如何改进原有的源代码。
我认为这是值得来分析一个程序使用FxCop就定期的基础上。
我不会感到惊讶，如果有些软件开发项目或企业所需的所有代码的书面发展，收益率没有警告或批评FxCop 。
规则可以添加或删除从FxCop数据库，根据需要。
FxCop是一个开放源代码，免费程序。
6.3 “Reflector for .NET” ： decompiler /分析仪
从Lutz Roeder's互联网站点：
"Reflector is the class browser, explorer, analyzer and documentation viewer for .NET. Reflector allows to easily view, navigate, search, decompile and analyze .NET assemblies in C#, Visual Basic and IL."
“Reflector”可以帮助一个人研究如何第三党的图书馆是书面。
有时将是非常有用的确切知道如何的一种方法在一个大会是落实。
如果一种方法表现在一个意想不到的或神秘的方式，然后“Reflector”可以用来见的执行情况。
所看到的执行情况，程序员可以工作，围绕所引起的问题的具体实现图书馆的方法。
一个朋友告诉我， “Reflector”帮助他了解更多有关的行为不佳的记录方法，在Microsoft执行该Framework Class Libraries (FCL) 。
“Reflector”可能会有所帮助时，文件一个图书馆的方法构成的，只有几句话，如“集的价值”或“事件处理程序” 。
如果一个库函数调用失败，为一不明原因（当所有的参数，似乎有效） ，然后利用“Reflector”看看执行图书馆的功能，可能揭示了失败的原因。
“Reflector”执行一些“逆向工程的”一个.NET程序或大会。
其他公用设施，其中可能包括“Reflector”本身，可以产生的源代码程序或集会建成的基础上模糊的源代码。
这显然是一个令人关切的一些开发商和投资者。
（ 2006 July ： Reflector.zip是版本4.2.45.0 ）
7. 因特网讨论论坛
Google搜索是最好的方式，找到答案的具体问题对任何话题，但下面的网站多次出现在搜索结果中为C#和.NET问题。
网站下面是可怕，为探索许多冷静的东西，人们所做的与C#和.NET 。
“The Code Project”网站拥有数以千计的令人感兴趣和有用的文章，为C# ， C++ ，和其他语言及编程范式。
该“MSDN Code Gallery”网站有很多有趣的文章和代码样本相关Microsoft技术。
与其他因特网网站的相关C#和.NET ：
8. 一般注释
8.1 平台独立性
该Intermediate Language (IL)一样， Java “字节码” ，是平台独立。
任何.NET兼容的编译器会生成平台独立Intermediate Language (IL)代码形式的程序或集会。
程序打包为可执行文件（ “*.exe”档案）必须有一些平台依赖性代码具体到一个操作系统，以便得到适当的解释，并展开为可执行软件语境中的特定操作系统。
不过，本土的可执行部分的软件文件，只是引用.NET CLR引擎，提交IL代码包含在软件文件的执行由CLR引擎。
Microsoft提供了一个实施该.NET水电费（编译器， ...),和实施的Framework Class Library (FCL) ，只为Windows作业系统。
该Mono Project提供了实现的.NET水电费（编译器， ...),和实现该Framework Class Library (FCL) ，用于以下操作系统： Windows ， Linux ， MacOS X ， BSD 。
8.2 速度相比，与non-CLR C / C++
该Common Language Runtime (CLR)方面.NET是的上下文中一C#程序执行。
该CLR执行“垃圾收集”和使程序能够引用职能，在“非托管”图书馆（所有的图书馆没有落实在Intermediate Language (IL) ） 。
任何功能是否多于纯数学，纯字符串操作，或纯记忆体复制，将引用的职能，在“非托管”图书馆。
所有的文件操作，插座行动，制定行动，投入业务（鼠标，键盘） ，输出业务（控制台） ，平台线程行动，精密计时器业务，窗口业务等，将引用的职能，在“非托管图书馆” 。
不幸的是，机制，引用“非托管”职能从CLR需要一个相当长的时间。
因此，整体的速度，程序执行，在上下文的CLR是noticably慢的程式，可引用“非托管”函数直接。
对于特定类型的软件，速度也很重要。
对于特定类型的软件，速度可以作出重要的差异，在主观或心理的经验，一个人使用该软件。
对于特定类型的软件，速度，可以使差异实现的目标和失败的。
多线程，增加CPU速度，以及改善该CLR代码发电设施，将有助于软件执行语境中的该CLR执行速度更快。
不过，任何的程式码执行外CLR ，并调用平台图书馆直接，难免会执行显着快于软件，执行与上下文的CLR 。
保证所提出的CLR ，以C#软件，如安全弥合差距，托管代码和非托管代码，是在成本，这是不太可能减少。
因此，任何程序，这是非常密集的平台（例如：三维仿真或游戏，文件处理器，网络服务器等） ，可能是执行一个量级更快以外的CLR比时，执行内部CLR 。
不同的是巨大的。
此外，任何程序都执行了大量的低层次的操纵数据将执行明显快以外CLR比内部CLR 。
程序执行语境中的该CLR执行不够快是有益的许多实际用途。
作为CPU速度增加，并作为代码更好地利用多个CPUs ，程序执行，在上下文的CLR将可用于更多的任务，需要高企的计算。
不过，在中2008该CLR仍是不适合3D游戏的任何精密的，除非有非常积极的努力，作出的数目减少函数调用，以三维图书馆（ OpenGL或Direct3D ） ，可能是使用的概念，如“着色程式”和“显示清单” ;有所减少的数目函数调用。
