RealProxy允许您为现有类型创建自己的代理。

这是非常先进的，我没有见过其他人使用它——这可能意味着它对大多数人来说真的没有那么有用——但这是值得了解的事情之一。

基本上，.NET RealProxy类允许您创建另一种类型的透明代理。在这种情况下，透明意味着它看起来完全像客户端的代理目标对象——但实际上不是：它是从RealProxy派生的类的实例。

这使您可以在客户端和在实际目标对象上调用的任何方法或财产之间应用强大而全面的拦截和“中介”服务。将此功能与工厂模式（IoC等）结合起来，您可以将透明代理而不是真实对象交回，从而允许您拦截对真实对象的所有调用，并在每次方法调用前后执行操作。事实上，我相信这正是.NET用于跨应用程序域、进程和计算机边界远程处理的功能：.NET拦截所有访问，向远程对象发送序列化信息，接收响应，并将其返回到代码。

也许有一个例子可以说明这是如何有用的：我为我作为企业架构师的最后一份工作创建了一个参考服务堆栈，它指定了部门内任何新WCF服务的标准内部组合（“堆栈”）。该模型要求Foo服务的数据访问层实现IDAL＜Foo＞：创建Foo，读取Foo，更新Foo，删除Foo。服务开发人员使用（来自我的）提供的公共代码来定位和加载服务所需的DAL：

IDAL<T> GetDAL<T>(); // retrieve data access layer for entity T

该公司的数据访问策略常常受到性能挑战。作为一名架构师，我不能监督每一个服务开发人员，以确保他/她编写了一个高性能的数据访问层。但我在GetDAL工厂模式中可以做的是为请求的DAL创建一个透明的代理（一旦公共服务模型代码找到了DLL并加载了它），并使用高性能计时API来配置对DAL的任何方法的所有调用。然后，对落后者进行排名只是按照总时间降序排序DAL呼叫计时的问题。与开发评测（例如在IDE中）相比，这种评测的优势在于它也可以在生产环境中进行，以确保SLA。

下面是我为“实体分析器”编写的测试代码示例，这是用一行为任何类型创建分析代理的常见代码：

[Test, Category("ProfileEntity")]
public void MyTest()
{
    // this is the object that we want profiled.
    // we would normally pass this around and call
    // methods on this instance.
    DALToBeProfiled dal = new DALToBeProfiled();

    // To profile, instead we obtain our proxy
    // and pass it around instead.
    DALToBeProfiled dalProxy = (DALToBeProfiled)EntityProfiler.Instance(dal);

    // or...
    DALToBeProfiled dalProxy2 = EntityProfiler<DALToBeProfiled>.Instance(dal);

    // Now use proxy wherever we would have used the original...
    // All methods' timings are automatically recorded
    // with a high-resolution timer
    DoStuffToThisObject(dalProxy);

    // Output profiling results
    ProfileManager.Instance.ToConsole();
}

同样，这让您可以截获客户端对目标对象调用的所有方法和财产！在RealProxy派生类中，必须重写Invoke：

[System.ComponentModel.EditorBrowsable(System.ComponentModel.EditorBrowsableState.Never)]
[SecurityPermission(SecurityAction.LinkDemand, 
    Flags = SecurityPermissionFlag.Infrastructure)] // per FxCop
public override IMessage Invoke(IMessage msg)
{
    IMethodCallMessage msgMethodCall = msg as IMethodCallMessage;
    Debug.Assert(msgMethodCall != null); // should not be null - research Invoke if this trips. KWB 2009.05.28

    // The MethodCallMessageWrapper
    // provides read/write access to the method 
    // call arguments. 
    MethodCallMessageWrapper mc =
        new MethodCallMessageWrapper(msgMethodCall);

    // This is the reflected method base of the called method. 
    MethodInfo mi = (MethodInfo)mc.MethodBase;

    IMessage retval = null;

    // Pass the call to the method and get our return value
    string profileName = ProfileClassName + "." + mi.Name;

    using (ProfileManager.Start(profileName))
    {
        IMessage myReturnMessage =
           RemotingServices.ExecuteMessage(_target, msgMethodCall);

        retval = myReturnMessage;
    }

    return retval;
}

.NET的功能是不是很迷人？唯一的限制是目标类型必须从MarshalByRefObject派生。我希望这对某人有帮助。

通过从匿名方法访问本地变量，您可以使用新的控制流逻辑包装任何代码，而不必将该代码分解到另一个方法中。方法外部声明的局部变量在方法内部可用，例如以下示例中的endOfLineChar局部变量：

http://aaronls.wordpress.com/2010/02/02/retrying-on-exception-conditionally/

使用这个怎么样：

#if DEBUG
            Console.Write("Debugging");
#else
            Console.Write("Final");
#endif

当您使用定义的DEBUG编译解决方案时，它将输出“调试”。

如果您的编译设置为Release，它将写为“Final”。

很多人不知道的一件事是C#引入的一些预处理器指令。您可以使用#error这是一个错误。生成编译器错误和#warning这是一个警告。

当我使用自上而下的方法进行开发时，我通常使用这些作为“待办事项”列表。我将#error实现此函数，或#warning最终实现此角案例作为提醒。

还有ThreadStaticAttribute可以使每个线程的静态字段唯一，因此您可以拥有强类型的线程本地存储。

即使扩展方法不是那么秘密（LINQ是基于它们的），对于实用程序助手方法来说，它们的有用性和可读性可能并不明显：

//for adding multiple elements to a collection that doesn't have AddRange
//e.g., collection.Add(item1, item2, itemN);
static void Add<T>(this ICollection<T> coll, params T[] items)
 { foreach (var item in items) coll.Add(item);
 }

//like string.Format() but with custom string representation of arguments
//e.g., "{0} {1} {2}".Format<Custom>(c=>c.Name,"string",new object(),new Custom())
//      result: "string {System.Object} Custom1Name"
static string Format<T>(this string format, Func<T,object> select, params object[] args)
 { for(int i=0; i < args.Length; ++i)
    { var x = args[i] as T;
      if (x != null) args[i] = select(x);
    }
   return string.Format(format, args);
 }

我称此为AutoDebug，因为您可以根据bool值（也可以存储为项目用户设置）在需要的位置和时间进行调试。

例子：

//Place at top of your code
public UseAutoDebug = true;


//Place anywhere in your code including catch areas in try/catch blocks
Debug.Assert(!this.UseAutoDebug);

只需将上述内容放在try/catch块或代码的其他区域，并将UseAutoDebug设置为true或false，然后随时进行调试即可。

您可以将此代码保留在原位，并在测试时打开和关闭此功能。您还可以将其保存为项目设置，并在部署后手动更改，以便在需要时/如果需要时从用户处获取其他错误信息。

在这里，您可以看到一个在Visual Studio C#项目模板中使用此技术的功能和工作示例，其中大量使用此技术：

http://code.msdn.microsoft.com/SEHE