个人才疏学浅，以下是我认为的答案
中级.NET开发人员
· 阐述面向接口、面向对象、面向方面编程的区别
面向对象不好解释，可以理解为以一切元素都是对象，在设计时以对象为单位，考虑它的属性及方法。设计中采用了封装、继承、抽象的手法
面向接口本身就是面向对象的，无所谓区别，只不过面向接口的好处是耦合性低
面向方面Aspect-Oriented Programming (AOP)就是大名鼎鼎的AOP。其实有点象struts里的拦截。
举例：假设有在一个应用系统中，有一个共享的数据必须被并发同时访问，首先，将这个数据封装在数据对象中，称为Data Class，同时，将有多个访问类，专门用于在同一时刻访问这同一个数据对象。
为了完成上述并发访问同一资源的功能，需要引入锁Lock的概念，也就是说，某个时刻，当有一个访问类访问这个数据对象时，这个数据对象必须上锁Locked，用完后就立即解锁unLocked，再供其它访问类访问。
· 什么是Interface？它与Class有什么区别？
接口可以理解成一种特殊的类，由常量和抽象方法组成的特殊类。
接口不能实例化;
接口中的方法没有方法体{};
继承接口的类一定要实现接口中定义的方法；
类可以实例化，可以定义自己的字段，属性，方法等等；
类可以继承多个接口，但只能继承一个类！
· 什么是反射?
提供了一种使用类名和方法名来访问方法的机制。
· 使用ASMX的XML Web服务与使用SOAP的.NET Remoting的区别?
SOAP是简单对象访问协议，Web服务正是通过WSDL来约定服务器和客户端基于xml的SOAP来通讯，而无论客户端和服务器不需要知道对方的平台、编程语言等信息。
.NET Remoting本质是为了交互更为复杂的对象，甚至需要管理远程对象的生命周期，所以客户端必须了解服务器对象的详细信息，虽然.NET Remoting支持使用SOAP，但对于客户端来说还是必须了解服务器对象的详细信息。
· 类型系统是由XMLSchema表示的吗？CLS是XMLSchema表示的吗？
Are the type system represented by XmlSchema and the CLS isomorphic?
我觉得问题是这样的，XMLSchema和CLS的类型系统相似吗？
XmlSchema是一个特定的XML文档必须满足的一套标准。这些标准能够描述不同的数据类型。比如：xs:Boolean
CLS不管值类型还是引用类型都是一套类型系统，比如System.Boolean.
像不像？你说呢？
· 从概念上阐述前期绑定（early-binding）和后期绑定（late-binding）的区别?
如果方法在编译时就确定就是前期绑定，如果在运行时才确定的叫后期绑定。
举个例子，比如spring在运行时才取类和类的对象，就是后期绑定
· 调用Assembly.Load算静态引用还是动态引用？
个人理解其实应该是一个反射，System.Reflection.Assembly.Load.所以嘛肯定动态引用了。因为静态引用在编译时就已经引用，并使用。
· 何时使用Assembly.LoadFrom？何时使用Assembly.LoadFile？
（声明以下是抄的，我不太了解Assembly.LoadFrom）。区别如下：
1、Assembly.LoadFile只载入相应的dll文件，比如Assembly.LoadFile("a.dll")，则载入a.dll，假如a.dll中引用了b.dll的话，b.dll并不会被载入。
Assembly.LoadFrom则不一样，它会载入dll文件及其引用的其他dll，比如上面的例子，b.dll也会被载入。
2、用Assembly.LoadFrom载入一个Assembly时，会先检查前面是否已经载入过相同名字的Assembly，比如a.dll有两个版本(版本1在目录1下，版本2放在目录2下)，程序一开始时载入了版本1，当使用Assembly.LoadFrom("2//a.dll")载入版本2时，不能载入，而是返回版本1。
Assembly.LoadFile的话则不会做这样的检查，比如上面的例子换成Assembly.LoadFile的话，则能正确载入版本2。
· 什么叫Assembly Qualified Name？它是一个文件名吗？它有什么不同？
它不是一个文件名，相比文件名，Assembly Qualified Name（程序集限定名称），更能确定一个程序集，它包含文件名，但同时包含版本，公钥，和区域。
· Assembly.Load("foo.dll"); 这句话是否正确？
Assembly name 有四个部分组成：Friendly Name，Culture, Pubilc Key(Token), Version。所以按他的意思这句话是错误的。
· 做强签名的assembly与不做强签名的assembly有什么不同？
强签名的程序集可以确认assembly name是唯一的（因为使用了public key token）。
强签名的程序集可以做成com。
强签名程序集可以安装到GAC中。
· DateTime是否可以为null?
不能为null，包括int什么的都不能等于null。当然2.0可以里加可空类型，但是在编译后你会发现可空类型其实是假的。
· 什么叫JIT？什么是NGEN？它们分别有什么限制和好处？
.NET 采用中间语言(IL)机制。Just In Time是指程序第一次运行的时候才进行把中间语言(IL)编译成机器代码，JIT增加了执行效率。本机映像生成器 (Ngen.exe) 是一个提高托管应用程序性能的工具。Ngen.exe 创建本机映像（包含经编译的特定于处理器的机器代码的文件），并将它们安装到本地计算机上的本机映像缓存中。运行库可从缓存中使用本机映像，而不是使用实时 (JIT) 编译器编译原始程序集。这是为什么asp.net程序第一次会比较慢，因为他是JIT。
· .NET CLR中一代的垃圾收集器是如何管理对象的生命周期的？什么叫非确定性终结？
垃圾收集器不能管理对象的生命周期吧？？我认为他只能跟踪对象的生命周期
先看一个对象的生命周期
1. 调用IL的newobj指令，分配一定空间的内存。
2. 初始化内存空间，比如设置为string类型。
3. 使用对象。
4. 销毁对象，执行清理
5. 回收内存
垃圾收集是在第4步。有三种方法：Finalize、Dispose、Close。
但垃圾收集执行的时机不定
的，初学者可以认为对象销毁的时机是在垃圾收集器认为对象需要被销毁的时候进行的，
他
对于程序员是透明的，初学者根本不需要知道垃圾收集器的存在。
个人理解的垃圾收集器的执行原理
：
周期性地遍历被应用当前引用的所有对象的列表。
在这个搜索过程中，凡是没有发现的对
象，都将准备予以销毁(但不并不是马上就销毁，只是先标记)。
这种算法表示如果对象的最
后一个引用也被解除时（意思是该对象再也不使用了，即可以销毁了），这时垃圾收集器并
不会立即接到通知，只有下一次对堆（heap）进行清扫时，才能发现这个情况。 说明了对象
在什么时候终结是不确定的，我认为这就是非确定性终结。进一步而言，执行垃圾收集清扫
次数越少，这类算法工作得越好。通常来说，堆的耗尽是收集清扫的触发条件。
· Finalize()和Dispose()之间的区别?
Finalize自动释放资源，Dispose()用于手动释放资源。
一. Finalize
Finalize很像C++的析构函数，我们在代码中的实现形式为这与C++的析构函数在形式上完全一样，但它的调用过程却大不相同。
~ClassName() {//释放你的非托管资源}
比如类A中实现了Finalize函数，在A的一个对象a被创建时（准确的说应该是构造函数被调用之前），它的指针被插入到一个finalization链表中；在GC运行时，它将查找finalization链表中的对象指针，如果此时a已经是垃圾对象的话，它会被移入一个freachable队列中，最后GC会调用一个高优先级线程，这个线程专门负责遍历freachable队列并调用队列中所有对象的Finalize方法，至此，对象a中的非托管资源才得到了释放（当然前提是你正确实现了它的Finalize方法），而a所占用的内存资源则必需等到下一次GC才能得到释放，所以一个实现了Finalize方法的对象必需等两次GC才能被完全释放。
由于Finalize是由GC负责调用，所以可以说是一种自动的释放方式。但是这里面要注意两个问题：第一，由于无法确定GC何时会运作，因此可能很长的一段时间里对象的资源都没有得到释放，这对于一些关键资源而言是非常要命的。第二，由于负责调用Finalize的线程并不保证各个对象的Finalize的调用顺序，这可能会带来微妙的依赖性问题。如果你在对象a的Finalize中引用了对象b，而a和b两者都实现了Finalize，那么如果b的Finalize先被调用的话，随后在调用a的Finalize时就会出现问题，因为它引用了一个已经被释放的资源。因此，在Finalize方法中应该尽量避免引用其他实现了Finalize方法的对象。
可见，这种“自动”释放资源的方法并不能满足我们的需要，因为我们不能显示的调用它（只能由GC调用），而且会产生依赖型问题。我们需要更准确的控制资源的释放。
二. Dispose
Dispose是提供给我们显示调用的方法。由于对Dispose的实现很容易出现问题，所以在一些书籍上（如《Effective C#》和《Applied Microsoft.Net Framework Programming》）给出了一个特定的实现模式：
class DisposePattern :IDisposable
{
private System.IO.FileStream fs = new System.IO.FileStream("test.txt", System.IO.FileMode.Create);
~DisposePattern()
{
Dispose(false);
}
IDisposable Members#region IDisposable Members
public void Dispose()
{
//告诉GC不需要再调用Finalize方法，
//因为资源已经被显示清理
GC.SuppressFinalize(this);
Dispose(true);
}
#endregion
protected virtual void Dispose(bool disposing)
{
//由于Dispose方法可能被多线程调用，
//所以加锁以确保线程安全
lock (this)
{
if (disposing)
{
//说明对象的Finalize方法并没有被执行，
//在这里可以安全的引用其他实现了Finalize方法的对象
}
if (fs != null)
{
fs.Dispose();
fs = null; //标识资源已经清理，避免多次释放
}
}
}
}
在注释中已经有了比较清楚的描述，另外还有一点需要说明：如果DisposePattern类是派生自基类B，而B是一个实现了Dispose的类，那么DisposePattern中只需要override基类B的带参的Dispose方法即可，而不需要重写无参的Dispose和Finalize方法，此时Dispose的实现为：
class DerivedClass : DisposePattern
{
protected override void Dispose(bool disposing)
{
lock (this)
{
try
{
//清理自己的非托管资源，
//实现模式与DisposePattern相同
}
finally
{
base.Dispose(disposing);
}
}
}
}
当然，如果DerivedClass本身没有什么资源需要清理，那么就不需要重写Dispose方法了，正如我们平时做的一些对话框，虽然都是继承于System.Windows.Forms.Form，但我们常常不需要去重写基类Form的Dispose方法，因为本身没有什么非托管的咚咚需要释放。
了解GC的脾性在很多时候是非常必要的，起码在出现资源泄漏问题的时候你不至于手足无措。我写过一个生成excel报表的控件，其中对excel对象的释放就让我忙活了一阵。如果你做过excel开发的话，可能也遇到过结束excel进程之类的问题，特别是包装成一个供别人调用的库时，何时释放excel对象以确保进程结束是一个关键问题。当然，GC的内部机制非常复杂，还有许多内容可挖，但了解所有细节的成本太高，只需了解基础，够用就好。
· using() 语法有用吗？什么是IDisposable？它是如何实现确定性终结的。
using()能自动调用Dispose方法
比如：using()会自动调用MyObject的Dispose方法
using ( MyObject myObject = new MyObject ( ) )
{
Console.WriteLine ( "quit" ) ;
}
IDisposiable是显示释放对象的接口，实现IDisposiable接口的类，可以显示的释放对象。
，通过编写Dispose方法来实现显式释放资源；
// C#
class MyClass : IDisposable
{
public MyClass() {} // 构造函数
~MyClass() {} // 析构方法 (不确定的) (编译器通过重载virtual void Finalize来实现)，与C++/CLI的!MyClass()等效
public void Dispose() {} // Dispose方法
public static void Test()
{
using(MyClass auto = new MyClass())
{ /* 使用auto对象 */ }
// 因为使用了using句法，编译器自动调用auto.Dispose()
// 以上代码等效于:
MyClass user = new MyClass();
try { /* 使用user对象 */ }
finally { user.Dispose(); }
}
}
· tasklist /m "mscor*" 这句命令是干嘛的？
列出所有使用了以" mscor"作为开头的dll或者exe的进程和模块信息
· in-proc和out-of-proc的区别
in-proc是进程内，进程内能共享代码和数据块，out-of-proc是进程外，进程外的互操作需要用进程间通讯来实现。
· .NET里的哪一项技术能够实现out-of-proc通讯？
.Net Remoting技术或者WCF技术
· 当你在ASP.NET中运行一个组件时，它在Windows XP, Windows 2000, Windows 2003上分别跑在哪个进程里面？
Xp : aspnet_Wp.exe
Windows 2000 : inetinfo.exe
Windows 2003 : w3wp.exe