我觉得混淆一个dll好像没用处

[dsf4t6]

把数据库连接字符串放在dll中，然后对dll进行混淆，就像在下面这样的：

public class A  // 公共类名字A不改
{
   public string MySpecialMethod(string para) // 公共方法的签名不改
   {
        <>A.C _k = B.C.F();  // 函数实现可以混淆
        _k.CG();
        if (B<F>())
        {
            F.T.CC(_k);
        }
        return  _KKZZ(_k.PU(), para);
   }
   private void _KKZZ(string s1, string s2)  // 私有方法名字等可以更改
   {
      //...
   }
}

虽然这样可以将dll进行混淆，但是我认为这样做的意义不大吧。因为，有工具可以将dll提取出来，提出来之后，他可以随便建一个简单的项目，然后引用这个dll，然后在他的项目中调用dll里面的方法，这样，就可以得到数据库连接字符串了诶。
不知道我的理解是否正确呢？

[zzyhost]

加个密码。。

[皮特胖胖]

混淆的用处本身就不大，吓唬吓唬行外人的。。 针对DLL，除了混淆之外，可以增加一些方法，比如字符串加密，主程序提供密码给dll解密，以及判断调用源，不是自己写的程序调用的就pass掉。。

[我叫小菜菜]

客户端从来就不可信，这是最基本的原则。 所以关键部分都放在服务器上跑，而对客户端进行授权和验证。 最强大的防御，还是内网环境和断网环境。

[ajianchina]

形同掩耳盗铃，用wcf吧。

[以专业开发人员为伍]

就程序来说，这只是单机小程序，而不是c/s程序。这不过是用了数据库系统的c/s驱动而已，而程序本身其实是单机的。 而一个真正的c/s系统，服务器端是你自己开发的，用户拿不到。还用什么混淆呢？用户根本拿不到什么dll。就算是拿到了dll，它也上不去服务器端局域网。

[Forty2]

把密钥（这里指广义的秘钥，包括秘密算法等等）放在客户端，本来就是什么东西都不能阻止客户使用它。 但是可以让客户‘保管’特定的密钥，那么，出了问题可以知道是哪个客户对此负责(Accountability)。 最严格的是让客户每次使用都输入分配给他的用户名和密码。 其次，可以让客户安全的保护分配给他的密钥，比如用操作系统的密钥容器（Key Container）来存放密码。

[xuzuning]

1、没有包含专利技术，没有混淆的必要 2、再怎么混淆，也不会改变字符串常量的原始形态 3、远程访问数据库是需要数据库授权的。 4、如果你的数据库授权全世界的机器都可访问，那么也就没必要担心连接串被泄露了（你本来就该给他的）

[娃都会打酱油了]

混淆技术本来就只是用来混淆代码的，不是混淆字符串的