.Net Reactor 是一款比较不错的混淆工具，比VS自带的那个好用很多，一直以来也陪伴着我们的成长，虽然没有完美的混淆工具，不过也算还是不错的，至少能在一定程度上对DLL进行一定的保护处理。

不过最近客户反映我们在混合框架删除操作的时候，没有如期的实现删除操作，由于混合框架是基于Web API / WCF这样的分布式开发方式，因此和普通跟踪的方式有所不同，针对Web API的使用是比较广泛的在云端实现数据集中管理的一种方式，相对普通的调试来说，难度增加了一些，需要在服务端（本篇主要是Web API操作）进行调试，以及在客户端界面进行联合调试处理。

本篇随笔主要介绍如何在碰到基于分布式处理数据的接口的时候，对错误问题的分析和逐步缩小范围的方式进行排查，最终解决问题的分析处理过程。

1、定位问题的发生

在我们出现问题的时候，往往需要定位在那个部分出现了错误，首先我们在客户端和服务端都需要进行跟踪调试，首先我们需要在Web  API 层跟踪对应的控制器操作是否获得对应要删除记录的ID值。

我们前面功能测试的时候，发现所有删除操作都出现了无法删除的问题，因此很可能是没有传递ID值，或者转换过程中出现了问题。

我们服务器端的删除操作接口如下所示。

        /// <summary>
        /// 根据指定对象的ID,从数据库中删除指定对象(用于整型主键)
        /// </summary>
        /// <param name="key">指定对象的ID</param>
        /// <returns>执行成功返回<c>true</c>，否则为<c>false</c>。</returns>
        [HttpPost]
        public virtual CommonResult Delete(KeyInfo keyInfo, string token, string signature, string timestamp, string nonce, string appid)
        {
            //检查用户是否有权限，否则抛出MyDenyAccessException异常
            base.CheckAuthorized(AuthorizeKey.DeleteKey, token, signature, timestamp, nonce, appid);

            CommonResult result = new CommonResult();
            try
            {
                if (keyInfo != null)
                {
                    result.Success = baseBLL.Delete(keyInfo.id);
                }
            }
            catch (Exception ex)
            {
                LogTextHelper.Error(ex);//错误记录
                result.ErrorMessage = ex.Message;
            }
            return result;
        }

其中的KeyInfo类是我们定义的一个实体类，定义代码如下所示。

    /// <summary>
    /// 用于删除的ID对象
    /// </summary>
    [Serializable]
    public class KeyInfo
    {
        /// <summary>
        /// ID主键
        /// </summary>public object id { get; set; }
    }

我们在调试Web API控制器的时候，无法获得KeyInfo参数的值，如下界面所示。

 那么可能KeyInfo无法被反序列化，又或者是KeyInfo没有传递过来，我们跟踪对应的接口，方向本来应该在客户端POST提交的ID信息，无法提交过来。

这个是针对客户端提交操作的抓包处理，本来想用Fiddler来抓取的，不过Fiddler好像无法直接抓取localhost的请求包体，通过代理设置没有处理成功，改用以前用的很顺手的 HttpAnalyzer，直接运行就可以抓取了，非常方便。

通过上面的操作，我们发现数据没有提交到控制器里面，因此排除Web API控制器反序列化对象的时候丢掉值的可能，而是客户端根本没有提交数据过来。

2、定位具体的值丢失位置

那么我们回到对删除操作的统一处理方法里面看看，有Delete和Delete2操作类似，分别对应不同类型处理。

 我们发现这里的处理，是直接把ID传递过来构建一个匿名对象，然后序列化为JSON字符串提交给Web API控制器处理的。在界面上主要就是通过统一调用进行删除的，传递ID给对应接口进行处理的。

以权限系统模块，用户删除操作为例，它的界面端处理代码如下所示。

 以上代码我增加了一行用来记录是否获得ID的内容的，通过日志记录，可以看到有ID传递给接口处理了。

 这样看到，问题出现在接口的处理里面，也就是可能由于我对DLL采用了混淆操作，导致的匿名类解析出现了问题了。

我们首先重写一下具体类的删除接口操作，跟踪一下问题。

 

  为了有效验证我们的问题出现在这里，我们对比勾选和取消了红色勾选，编译后的代码进行测试。

对比处理结果，我们可以看到混淆前后，接口获得的数据不同，因此可以知道是混淆导致匿名类处理出现了问题。

 于是，我们对所有相关的DLL，取消对应的这个混淆选项，运行可以得到正确的结果。

 以上就是我们对这个.Net Reactor混淆导致匿名类处理出现的问题处理分析，其中主要涉及到了客户端localhost地址的本地抓包处理，采用了比较方便易用的HttpAnalyzer来分析是否数据提交有问题，还是数据解析出现问题，定位问题的边界，然后逐步对界面和接口部分进行分析。

由于对DLL混淆导致的错误问题，一般来说不易推断，所以尽可能多的列出可能影响的因素，逐一测试解决，慢慢缩小范围即可获得解决问题的办法。