好的，我想我现在已经弄清楚了。我一直在处理的实际上是两个不同的问题。
第一个问题是 ASP.NET 开发服务器似乎只愿意从项目/bin文件夹中获取其 DLL。如果设置为Any CPU ，您的项目将在那里构建，但如果设置为x86or x64，则默认为在bin/x86/Debugor中构建bin/x64/Debug。如果您设置为默认构建位置x86或x64使用默认构建位置，则开发服务器仍将尝试从文件夹的根目录中获取 DLL /bin。
如果您从未将项目构建为Any CPU，或者自上次以来已清理过该/bin文件夹，则它根本找不到您的 DLL，并且开发服务器将显示一条错误消息，例如“无法加载类型 'WebDownlink.全球的'。” 关于您的Global.asax文件（WebDownlink项目的名称空间在哪里）。这意味着它无法加载您的命名空间，这是因为它无法找到您的 DLL，因为它只在文件夹的根目录中查找/bin。
如果您已将项目构建为 asAny CPU然后切换到在x86or中构建它x64，那么您的新构建将位于适当的子目录中，但开发服务器仍会从您上次Any CPU构建中获取文件。但是，Visual Studio 调试器将使用您刚刚构建的文件，因此，如果您在上次Any CPU构建后更改了任何内容，您将收到不同的源代码错误，并且调试将无法正常工作。如果您没有更改任何内容，那么调试将起作用，但开发服务器仍将运行该Any CPU版本，如果您尝试做任何事关重要的事情，这可能会让您感到困惑。
对此的正确解决方案似乎是将您的x86模式配置为在文件夹的根/bin目录而不是文件夹中构建/bin/x86/Debug。或者，也许一开始就不要引用任何非托管 DLL。
这与第二个问题相吻合，即 ASP.NET 开发服务器仅在 32 位模式下运行，而 64 位系统上的IIS应用程序池仅在 64 位模式下运行（如果您知道一种方法更改其中任何一个，请让我知道）。如果您需要将代码链接到无法构建为的非托管 DLL，Any CPU则必须考虑到这一点。这就是为什么我只x86在上面提到的原因——改变你的构建位置是没有意义的，x64因为开发服务器无论如何都不会运行它。
幸运的是，我有我的代码引用的 DLL 的源代码，并且它不引用任何其他内容，因此我可以轻松地在 32 位和 64 位模式下构建它，以便在开发服务器和完整的 IIS 上运行它. 如果您引用的是无法重建的 32 位 DLL，那么您要么必须在 32 位机器上部署，要么想办法让 IIS 应用程序池以 32 位运行，而我做不到。吨。如果您的 DLL 是 64 位的并且无法重建，那么您只需在完整的 IIS 上对与它相关的代码进行所有调试。
所以我的解决方案是以 32 位构建我的 DLL，重置引用，然后以 32 位模式构建，输出路径设置为/bin. 当我想部署时，我在 64 位中重建 DLL，重置引用，在 64 位中构建项目，然后部署到 IIS。