企业官网建设流程全解析

简介：这是一份面向 .NET 开发者的 MySQL 8.0.13 数据访问组件包，采用 x86 构建，适用于桌面应用、Web 项目以及需要将 MySQL 作为数据源的各类 C# 服务端场景。资源围绕 MySql.Data 核心库，并针对 EF6 与 EF Core 分别提供适配程序集，可帮助解决在 .NET 环境中引用 MySQL 驱动、接入数据访问层，以及离线部署时缺少官方安装包、无法直接执行安装程序等问题。压缩包为 rar 格式，共 12 个文件，其中 6 个 dll 提供运行时程序集，5 个 xml 提供 API 注释文档，1 个 installstate 记录安装状态，整体仅 560KB，结构紧凑，便于复制到项目中引用或归档保存。已有 1423 人学习/下载，适合需要手动管理依赖、定位驱动冲突或进行版本归档的 .NET 开发人员。资源中除核心数据访问主程序集外，还包含 Web 适配与 Protobuf 序列化等关联依赖，配套的 XML 文档可在代码编写时显示智能提示，帮助开发者快速了解程序集 API，减少排查引用错误的时间，提升集成效率。 前阵子做了个 PC 端演示工具，Unity 2021.3.32f1，IL2CPP，目标平台 Windows x86。逻辑不复杂：客户端启动后从一个远程 MySQL 拉配置表。编译一路绿灯，打包出来一运行直接抛 BadImageFormatException，查了一个下午才定位到 MySql.Data.dll 8.0.13 和整个进程架构的匹配关系。后来在几个技术交流群里发现，搜"MySql.Data.dll x86"的人真不少，大多是被 Unity 老工程或者 32 位 Windows 环境卡住的。这篇就把这个 DLL 的来龙去脉、获取方式、Unity 安置姿势、运行时报错排查，完整写一遍，给同样在这个坑里的朋友一个可复现的解决路径。

1. 一个 DLL 被冠上"x86"搜索词，背后的项目长什么样

1.1 Unity 2021.3.32 客户端直连 MySQL 的典型场景

Unity 项目要连 MySQL，最普遍的做法是引 Oracle 官方的 Connector/NET，也就是 MySql.Data.dll。它的 API 完全对标 ADO.NET：MySqlConnection、MySqlCommand、MySqlDataReader，用起来和 SqlClient 几乎一样。Unity 2019 到 2021 这几代 LTS 里，遇到配置下发、排行榜同步、账号验证这种需求，很多项目组会在服务端之外留一个"客户端直连数据库"的快捷通道，这时候 MySql.Data.dll 就是唯一桥梁。

我遇到的情况很典型：展会演示机是台老旧的 32 位 Windows 机器，Unity Build Settings 里 Architecture 只能选 x86，于是整个 Player 就是一个 32 位原生进程。这个进程里运行的所有托管程序集，架构必须兼容 x86。很多人第一次踩坑就是忽略了这一点：从 NuGet 拉一个 MySql.Data.dll 往 Assets 里一扔，Editor 里跑得欢，一打包就废。

1.2 8.0.13 为什么成为流传最广的"老版本"

8.0.13 是 Connector/NET 8.0 阶段一个相当稳的版本，2018 年末发布，同期的 MySQL 服务端也是 8.0.13。很多人其实不是主动选它，而是"历史遗留"——网上大量 Unity 连 MySQL 的教程写于 2018 到 2019 年，用的就是 8.0.11 到 8.0.13 这一段。项目从旧工程升级上来，为了少折腾，直接把这个 DLL 带进了新工程。

这个版本好在哪？它的托管依赖只有两个：Google.Protobuf 和 BouncyCastle.Crypto。到了 8.0.20 之后的版本，又陆续引入 System.Buffers、System.Memory 等新依赖，在 Unity 的旧 API 兼容级别下更容易出幺蛾子。所以 8.0.13 在 Unity 圈子里流传广，不是因为它新，而是因为它"够用、依赖少、教程多"。

1.3 先搞清楚：官方 DLL 其实不区分 x86/x64

这里要先纠正一个认知：官方发布的 MySql.Data.dll 本体是 AnyCPU 的，它本身不区分 32 位还是 64 位。真正让你需要去搜"x86 版本"的情况，通常是下面三种：

• 目标进程本身是 32 位（Unity x86 构建、老 WinForm 程序），整个依赖链里某个环节位宽不对。
• 你手里的 MySql.Data.dll 来自第三方下载站，被人用 x64 平台目标重新编译过。
• 依赖链中出现了原生库（少数连接特性会用 P/Invoke 调原生组件），原生库位宽和进程对不上。

所以"MySql.Data.dll x86"这个搜索词背后，真正的问题往往不是 DLL 文件本身，而是"进程位宽 + 依赖链"这一整条链路。带着这个前提去排查，比盲目替换 DLL 有效得多。

2. 进程位宽与程序集位宽：BadImageFormatException 是怎么来的

2.1 两个最典型的"架构不匹配"信号

架构不匹配最常见的两个报错，一个是 BadImageFormatException，一个是 FileLoadException。现象都是：编译全过，一运行就炸，而且炸的时机很飘忽——可能在 new MySqlConnection 的时候，可能在 Open() 的时候，也可能在某个静态方法第一次被 JIT 的时候。

这个异常的本质是 Windows 加载器的规则：进程位宽和加载目标的位宽必须一致。32 位进程不能加载 PE32+ 格式的 64 位原生库；反过来，64 位进程也不能加载被标记为 32BITREQ=1 的托管程序集。托管世界里 AnyCPU 算是一张"豁免牌"，但如果程序集被明确标记成 x64-only，32 位进程照样拒收。

2.2 AnyCPU 在 Unity Player 里的真实表现

很多人以为 AnyCPU 天下无敌，其实只对了一半。.NET Framework 下，AnyCPU 程序集在 64 位系统上默认以 64 位进程方式运行，在 32 位系统上以 32 位方式运行。这个"跟随系统"的特性，到了 Unity 里并不适用——Unity Player 的位宽在打包时就定了，托管 DLL 只能去适配 Player，而不是反过来。

更要命的是，AnyCPU 只能解决"托管程序集"这一层。Connector/NET 8.x 在某些连接特性上会通过原生层做事，比如老的压缩传输协议、部分认证流程。一旦原生依赖介入，位宽立刻变成硬约束。哪怕你手里的 MySql.Data.dll 是 AnyCPU，只要它实际链接的原生库是 x64 的，x86 Player 照样炸。这就是为什么排查的时候不能只看主 DLL，得看整条依赖链。

2.3 用 corflags 验证平台目标

排查架构问题别靠猜，用 corflags 看一眼最快。corflags 随 Visual Studio 的开发者命令行一起提供，直接执行：

corflags.exe MySql.Data.dll

官方 8.0.13 的 MySql.Data.dll，输出大概是 PE32 格式、ILONLY=1、32BITREQ=0，这才是标准的 AnyCPU。判断规则很简单：

• PE32 + 32BITREQ=1：纯 x86 程序集，只能进 32 位进程。
• PE32+ + 32BITREQ=0：x64 程序集，32 位进程加载必报 BadImageFormatException。
• PE32 + 32BITREQ=0：AnyCPU，x86 和 x64 进程都能加载。

如果你手里的 DLL 显示 PE32+，那基本可以确定是第三方重新编译过的 x64 版本，直接换官方文件就行。这一步能在五分钟内排除掉一半的"玄学报错"。

3. 从 Connector/NET 8.0.13 安装包里，取一份干净可用的程序集

3.1 下载 msi 与安装目录

获取 MySql.Data.dll 唯一推荐的渠道是 MySQL 官网的 Connector/NET 安装包。找到 8.0.13 版本，下载 mysql-connector-net-8.0.13.msi，安装路径默认是 C:\Program Files (x86)\MySQL\MySQL Connector Net 8.0.13\。注意这里路径名里有 "Program Files (x86)"，纯粹是因为 MySQL 安装器自己选择了 32 位安装目录，和 DLL 本身的位宽没关系，别被这个误导。

装完后，Assemblies 目录下会有几个子目录，分别对应不同的 .NET 运行环境。这一步选错，后面所有努力都白费。

3.2 按目标框架选程序集目录

Unity 2021.3.32 的项目，如果 Project Settings > Player > Api Compatibility Level 选的是 .NET Standard 2.0，就从 netstandard2.0 目录取；如果选的是 .NET Framework 4.x，就取 v4.5.2 或 v4.6.2。这个选择和 IL2CPP 的 AOT 编译有直接关系，建议先确认清楚再动手。

3.3 两个绑定依赖：Google.Protobuf 和 BouncyCastle

Connector/NET 8.0.13 有且仅有两个托管依赖，必须一起拷走：

• Google.Protobuf.dll：MySql.Data 内部用 Protobuf 做 X Protocol 通信。
• BouncyCastle.Crypto.dll：负责 caching_sha2_password 等认证加密算法。

如果你只拷了一个 MySql.Data.dll 进工程，编译照样能过，但运行到 Open() 时大概率报 "Could not load file or assembly 'Google.Protobuf, Version=3.5.1.0'..."。这两个依赖同样在安装目录里，或者从对应的 NuGet 包中获取。版本要和 MySql.Data 8.0.13 匹配，别随手拉个最新版 Protobuf 过来，程序集强名称对不上一样会炸。

4. 托管 DLL 在 Unity 工程里的正确安置方式

4.1 Plugins 根目录与 Inspector 平台设置

网上很多教程会让你把 DLL 丢进 Assets/Plugins/x86 目录，但这个目录其实是给原生插件（Native Plugin）用的。托管插件更稳妥的做法是放 Assets/Plugins 根目录，然后在 Inspector 里逐个设置 Platform Settings。这样做的好处是平台归属清晰，不会出现 Unity 打包器对子目录插件做额外处理的歧义。

具体设置：选中 DLL，Inspector 里勾选 Standalone（Windows 桌面平台），CPU 一栏选 x86，其他不需要的平台全部取消勾选。否则你以后打 Android 或 iOS 包时，Unity 会把 Windows 的 DLL 也塞进去，轻则报警告，重则编译直接报错。如果你同时要发布 x64 版本，就放两份：x86 设置一份，x64 设置一份，Unity 会按构建目标自动挑选。

4.2 最小可用代码与连接串参数

放好 DLL 后，建议先写一段最小代码验证链路，别一上来就接业务逻辑：

using System; using MySql.Data.MySqlClient; using UnityEngine; public class MySqlSmokeTest : MonoBehaviour { void Start() { string connStr = "Server=192.168.1.10;Port=3306;Database=game_db;" + "Uid=root;Pwd=your_password;CharSet=utf8mb4;SslMode=None;"; try { using (var conn = new MySqlConnection(connStr)) { conn.Open(); Debug.Log("MySQL connected, state=" + conn.State); using (var cmd = new MySqlCommand("SELECT id, name FROM player LIMIT 5", conn)) using (var reader = cmd.ExecuteReader()) { while (reader.Read()) Debug.Log(reader.GetInt32(0) + " - " + reader.GetString(1)); } } } catch (Exception ex) { Debug.LogError("MySQL error: " + ex); } } }

连接串里的 SslMode=None 是刚联调时最省事的配置，内网测试往往没有配证书，先保证能连上再谈加密。CharSet 推荐 utf8mb4，MySQL 8.0 默认字符集就是 utf8mb4，连接串不写的话，遇到 emoji 或生僻字对不上很容易乱码。

4.3 link.xml 防止 IL2CPP 裁剪

IL2CPP 打包时会把托管程序集转成 C++ 再编译，这个过程会做代码裁剪。裁剪器觉得"没被引用"的类型会被删掉，而 MySql.Data 这类大量走反射加载内部类型的库很容易被误砍。典型现象是：Editor 里一切正常，打包后 Open() 报 FileNotFoundException 或者 MissingMethodException，而且报错信息经常指向 MySqlConnection 这个入口类，误导你去查连接串。

解决方式是在 Assets 根目录放一个 link.xml：

<linker> <assembly fullname="MySql.Data" preserve="all"/> <assembly fullname="Google.Protobuf" preserve="all"/> <assembly fullname="BouncyCastle.Crypto" preserve="all"/> </linker>

如果项目开了更高强度的 Managed Stripping Level，三个程序集全部 preserve="all" 是最省心的。这是我把 8.0.13 接进 Unity 后踩的最深的一个坑，花的时间比架构不匹配还多。

5. 打包后最容易遇到的五个运行期错误

5.1 错误一：Could not load file or assembly 或其一依赖

这个报错的常见原因有三个：DLL 没放进 Plugins，Unity 根本没打进包；link.xml 缺失导致关键类型被裁剪；Google.Protobuf 或 BouncyCastle 没同步。排查第一步，打开打包产物目录，找到 Managed 文件夹，确认四个 DLL（MySql.Data 加两个依赖，有时还有 System 相关）都在。缺哪个补哪个，然后按第 4

本文还有配套的精品资源，点击获取