.NET framework是干什么的？
.NET Framework一般指Microsoft .NET Framework。
Microsoft .NET Framework是用于Windows的新托管代码编程模型。它将强大的功能与新技术结合起来，用于构建具有视觉上引人注目的用户体验的应用程序，实现跨技术边界的无缝通信，并且能支持各种业务流程。
Microsoft .NET Framework安全解决方案
.NET Framework安全解决方案基于管理代码的概念，以及由通用语言运行时（CLR）加强的安全规则。大部分管理代码需要进行验证以确保类型安全及预先定义好的其它属性的行为的安全。
例如，在验证的代码中，声明为接收4字节值的访问将拒绝提供8字节参数的调用，因为不是类型安全的。验证过程还确保了执行流只传送到已知的位置，如方法入口点--这个过程去除了跳转到任意位置执行的能力。
验证将阻止不是类型安全的代码执行，在它们引起破坏前捕获很多常见的编程错误。通常的弱点--如缓存溢出，对任意内存或没有初始化的内存的读取，对控件的随意传送--都不再可能出现。这将使最终用户受益，因为在他们执行代码前对其进行检查。
这也有益于开发人员，他们会发现很多常见错误（过去一直在困绕前开发）现在可以查明，并能阻止它们引起破坏。
扩展资料：
CLR内存管理
内存管理的自动化：在执行过程中管理应用程序的资源是一项单调而困难的工作。它会将你的注意力从你本应解决的问题中引开。而垃圾收集机制完全解决了程序员在编程过程中头痛的问题，跟踪内存的使用，并知道何时将它们释放。
在面向对象的环境中，每种类型都标识了对你的应用程序有用的某种资源。为了使用这些资源，你需要为类型分配内存。在应用中，访问一种资源要通过以下步骤：
（1）为类型分配内存。
（2）初始化内存，设置资源的初始状态并使其可用。
（3）通过访问该类型的实例成员来访问资源。
（4）卸下将被清除的资源状态。
（5）释放内存。
这一看似简单的过程在实际的编程中是产生错误的主要来源之一。更可怕的是：内存中的错误往往导致不可预见的结果。如果你有过编程的经验，想想看，有多少次你的程序因为内存访问错误而崩溃？
特别是计算机存在多根内存条时特别容易内存报错死机。建议升级电脑时换掉原来的内存，不要采用加内存的方式。
CLR要求所有的资源从可操控的堆（注：在此指一种内存结构）中分配。当一个进程被初始化后，CLR保留了一个未被分配的地址空间。这一区域叫做可操控堆。在堆中保持了指向下一个将被分配给对象的堆地址的指针(NEXT)。
初始状态下，该指针是保留地址空间的基地址。一个应用使用新的操作产生对象。此操作首先检查新对象需要字节的大小是否会超出保留空间。
如果对象大小合适，指向下一个地址的指针将指向堆中的这个对象，该对象的构造器被调用，新的操作返回对象的地址。
当一个应用请求建立一个对象时，地址空间可能不够大。堆将发现这一点（通过将新对象的大小与NEXT指针相加，并与堆的大小进行比较），这时垃圾收集器就将被调用。在这里，CLR引入了“代”的概念。代，指堆中对象产生的先后。
这样，垃圾收集器在将发生溢出时回收属于特定的“代”的对象，而不是回收堆中的所有对象。
（6）即时编译
在各种语言的编译器对源代码进行编译之后，在CLR环境中产生的是中间代码（出于兼容性与跨语言集成的考虑），其内容虽然有效，但在转化为本地代码之前它本身是不可执行的。这就是JIT编译器需要完成的工作。
这里需要说明一个问题：为什么要即时编译，而不是一次性的将中间代码文件进行编译？答案很简单：原因在于效率。在大型的应用中，你很少会用到程序的全部功能，这种边执行边编译的措施比一次性的完全编译效率更高。
CLR带有三个不同的JIT编译器，在Windows平台中，CLR带有三个不同的JIT编译器：
（1）缺省的编译器---主编译器，由它进行数据流分析并输出经过优化的本地代码，所有的中间代码指令均可被它处理。
（2）PREJIT，它建立在主JIT编译器之上。其运行方式更象一个传统的编译器：每当一个.NET组件被安装时它就运行。
（3）ECONOJIT，在并不充分优化的前提下，它能够快速完成IL代码到本地码的转换，编译速度与运行速度都非常快。
为了配合编译器的工作，在.NET SDK的安装路径下的/bin目录中有一个负责管理JIT的应用程序：jitman.exe。具体的使用参见联机帮助。
参考资料：
