从快速浏览来看，SQLCipher 似乎是作为 SQLite 源代码+修改的检查而分发的 - 这是多文件版本而不是“合并”。因此，您需要一个能够构建 SQLite 源的环境，这意味着一堆 unixy 应用程序。
就个人而言，我会在 SQLCipher 源档案和它包含的 SQLite 版本之间进行比较（根据 VERSION 文件判断，这似乎是 SQLCipher 1.8.2 的 SQLite 3.7.2） - 这应该给出哪些修改的想法，如果任何，都是对源 SQLite 文件以及特定于 SQLCipher 的列表文件进行的。
为了避免手动构建 OpenSSL 的麻烦，您可以获取预构建的版本，这可以消除 Perl 依赖项（iirc OpenSSL 可以使用 Visual C++ 构建，因此 MingW 不应成为依赖项）。
IfSQLCipher 作者并没有故意将他的特定代码部分从 SQLite 中分离出来，这很棘手（他可能会这样做，以通过销售 win32 二进制文件来赚取一些钱），您可以接受他的更改并与 SQLite 结合起来合并版本和预构建的 OpenSSL 二进制文件，这应该可以非常轻松地插入 Visual Studio 解决方案中。
当然，这意味着如果您想升级到较新版本的 SQLCipher，则必须执行提取步骤，但这可能是值得的，除非您真的想安装 cygwin 开发环境只是为了能够构建这个单一的库。
或者，您也许可以执行以下操作配置SQLCipher 在 *u*x 机器上的步骤（无论是 linux、*BSD 还是 Mac OS X shell），因为compile步骤不应该需要所有时髦的工具。
UPDATE:
我检查了 SQLite（版本 3.7.2）[http://www.sqlite.org/src/info/42537b6056] 并针对 SQLCipher 1.1.8 发行版运行了差异，这似乎是一个相当合理的提取任务修改部分：
Makefile.in - references added for the new crypto files.
tool/mksqlite3c.tcl: references added for the new crypto files.
src/pragma.c - one added block, marked /** BEGIN_CRYPTO **/
src/pager.c - one added block, marked /** BEGIN_CRYPTO **/
src/crypto.h - new file.
src/crypto.c - new file.
另外，仅仅为了获得 AES 加密支持而依赖 OpenSSL 似乎有点过分了——基于 SQLCipher 构建新的东西来使用专用的（而且更小的）AES 包会更好。
