vswhom-sys.rs

对 Jon Blow 的 VS 发现脚本 的纯 FFI。

请注意，原生代码 在某些情况下被发现会导致内存损坏。

文档

特别感谢

在 Patreon 上支持进一步开发的所有人，特别是

• ThePhD
• Embark Studios
• Jasper Bekkers

lib.rs:

对 Jon Blow 的 VS 发现脚本 的纯 FFI。

本 crate 的其余文档几乎直接从原始 C++ 源代码复制。

如何使用此代码

此文件的目的是在 Windows 上查找包含您可能需要链接的库的文件夹，如果您正在与任何编译的 C 或 C++ 代码链接。这对于许多希望提供兼容性的非 C++ 编程语言环境是必要的。

我们找到 Visual Studio 库所在的位置（例如，libvcruntime.lib），链接器和编译器可执行文件所在的位置（例如，link.exe），以及 Windows SDK 库所在的位置（kernel32.lib，libucrt.lib）。

我们都希望您不必担心这么多奇怪的依赖关系，但遗憾的是我们真的别无选择。

我并不声称这是解决这个问题的绝对最佳方式，到目前为止，我们只是简单地处理这些问题（如果你安装了多个版本的Visual Studio，我们将返回第一个而不是最新的）。但这种方式可以简单有效地解决你的基本问题，而且由于这里代码不多，修改和扩展都很方便。

以下是你需要了解的API

调用vswhom_find_visual_studio_and_windows_sdk()，查看结果路径，然后对结果调用vswhom_free_resources()。

在添加这些注释之前，这个文件大约有400行。你可能认为，做这样简单的事情需要这么多代码是非常多的。我同意。然而，微软自己针对这个问题的解决方案，称为“vswhere”，只是一个八千行的程序，分布在70个文件中，他们不无讽刺地将其发布到github。

这不是我编造的：https://github.com/Microsoft/vswhere

因此，有几个人发现有必要自己解决这个问题。在决定做什么的时候，我们参考了这些其他解决方案，其中最突出的是Ryan Saunderson的ziglang版本。

我讨厌这种代码。我们之所以必须这样做，本身就很愚蠢，而我们实际上需要采取的操作只是痛苦。如果编程总是这样，我会放弃。

我采取的另一个快捷方式是，这个程序硬编码为返回x64库的文件夹。如果你需要x86或arm，你可以对下面的代码进行轻微的修改，或者，如果足够的人想要这个，我可以在这里进行修改。