我有一个作为安装文件分发的 vb6-mysql 客户端-服务器桌面应用程序。
它使用 DLL 的所有逻辑操作以及数据库操作。EXE 和 DLL 安装在服务器和客户端机器中。当我说服务器仅意味着数据库驻留在该机器中时，EXE 或 DLL 没有其他区别。
当从客户端机器连接时，所有数据库操作都在 DLL 中完成，因此性能会降低。现在不可能将所有逻辑都更改为数据库。
是否可以仅将 DLL 存储在服务器计算机中并由客户端计算机使用相同的 DLL，以便数据库连接始终来自服务器本身？
将 DLL 转换为 Windows 服务是可能的解决方案吗？
您似乎正在尝试重新发现 n 层应用程序开发。
在 LAN中使用 VB6 完成此操作的常用方法是创建 ActiveX EXE 而不是 DLL，以便您可以使用 DCOM。但是 DCOM 不是您想通过 Internet 公开的东西。
对于这种情况，更典型的做法是使用 HTTP 或 HTTPS 等通用开放端口协议。几乎每个人都有防火墙设置，允许出站 HTTP 和 HTTPS 连接，并且大多数主要 Web 服务器都经过定期加固，以使它们更安全地暴露在 Internet 上。
使用 VB6 执行此操作的经典方法是使用 IIS 来托管远程数据服务，该服务使用一种“幕后”的 Web 服务形式，您的程序不会处理血淋淋的细节。然而，这是一种已弃用的方法，如今配置 IIS 和 RDS 组件可能是一件苦差事，因为它们在默认情况下被硬锁定。
这给您留下了诸如已弃用的 SOAP 工具包或诸如 PocketSOAP 套件中的第 3 方工具之类的东西……或者您可以自己动手。
从头开始这样做可能需要一些工作，但更灵活，允许使用 REST 代替本身具有优势的 SOAP。您可以使用您选择的任何可以与 VB6 一起工作的 Web 服务器（通过 CGI 等）。
从表面上看，最难证明的方法似乎是最简单的：通过 TCP 创建您自己的协议并编写一个 Windows 服务。这可能是所有选项中最灵活的，但它可能比其他选项需要更多的工作，并且您可以自行完成并确保其安全。您可能还会遇到防火墙问题，具体取决于您的客户端所在的位置以及那里的本地防火墙策略。
当我们可以依赖 DCOM 时，除了安全配置问题之外，问题相对较小。有了互联网，情况就完全不同了。
这真的不是你随便做的事情。即使假设您的数据库安全地暴露在 Internet 上也是幼稚的，应该重新考虑。