c# - 将 Entity Framework 与 Web 代理一起使用

Question

我有一个使用Entity Framework Model First 的项目。数据源在互联网上，我需要它使用网络/网络代理来工作。我用谷歌搜索了它，但找不到任何有用的结果，因为所有结果都是关于 EF 的实体代理。一些有用的代码:

连接字符串:

<add name="ConnectionName" connectionString="metadata=res://*/Latin.csdl|res://*/Latin.ssdl|res://*/Latin.msl;provider=System.Data.SqlClient;provider connection string=&quot;data source=mssqlserver.server.com;initial catalog=DatabaseName;user id=admin;password=adminPass;MultipleActiveResultSets=True;App=EntityFramework&quot;" providerName="System.Data.EntityClient" />

用法:

static void Main(string[] args)
    {

        //set the proxy
        var proxy = new WebProxy("109.32.24.24", 808);
        proxy.Credentials = new NetworkCredential("", "");
        WebRequest.DefaultWebProxy = proxy;

        var db = new ContextName();

        if (db.QNames.First().Name == "Testing")
        {
            Console.WriteLine("Success Connection!");
            Console.ReadKey();
        }

    }

这会引发网络连接错误。

---

编辑

---

网络的代理运行在 http 协议(protocol)之上。我知道 http 是您通常用来浏览网页的协议(protocol)，您通常不会用它连接到数据库 但它是唯一可用的协议(protocol)，这个问题就是关于它的。您可以将 Web 代理用于多个 .net 连接，甚至是 Web 服务，我的问题是关于将它与 EF 一起使用，我无法使其正常工作。最后一个解决方案可能是使用 Proxifier 之类的程序并将所有计算机的连接重定向到指定的 Web 代理，但这个想法是让它更易于配置。

Answer 1

this application may be running in a internetless network, that the only way for getting internet is using an HTTP proxy

那么你不能这样做，或者至少不容易。

当网络配置为只有 HTTP 流量可以离开网络时，您将被限制为……只能进行 HTTP 调用。 SQL Server 的有线协议(protocol)是自定义的专有二进制协议(protocol)，与 HTTP 完全不同。因此，如果 HTTP 是您唯一的出路，则您无法通过 HTTP 代理连接到 SQL Server 的远程实例。那是 why I asked what kind of proxy you're talking about ，因为例如 SOCKS 代理确实允许任意 TCP 连接通过它运行，并且 Windows supports it natively .

不过，您可以通过代理设置 HTTP 隧道。参见 Tunnel any kind of TCP traffic through HTTP/s .这假定您控制连接的两端，并且可以在您的应用程序软件旁边运行或安装任意软件(即隧道软件)。

这也可能会或可能不会工作，具体取决于客户端代理服务器的配置。

但是，这看起来像一个 XY problem .根据实际问题，有多种方法。

You do not want to expose, nor connect to SQL Server over the internet anyway .

也许您可以编写一个网络服务，然后您的应用程序会使用它。 Web 服务与 HTTP 通信，因此无需任何额外配置或软件即可通过 HTTP 代理连接。 Web 服务在 SQL Server 上或附近运行，您可以通过该服务公开您的业务逻辑 - 而无需公开您的 SQL Server。

另一种选择是 VPN 连接，但同样，这取决于实际问题以及您可以控制连接的哪一侧。