为什么即使在IIS中将“启用32位应用程序”设置为false，App_GlobalResources为什么也可以为x86编译？

Question

我正在处理的Web应用程序具有三个x86依赖项：

• Crystal Reports 32位运行时
• 一个古老的本地数据实用程序库
• 一个古老的本地日志库

我在登台服务器和本地计算机上执行了以下操作：

• 删除了32位CR运行时并安装了64位
• 反编译两个本地库，并将所需的代码放在Web应用程序中（并删除对两个程序集的引用）
• 在IIS中的应用程序池上将“启用32位应用程序”设置为false

Web应用程序现在具有64位依赖性（Lync UCMA SDK），这导致需要删除32位依赖性。 问题是，现在我从浏览器的IIS或命令行（如果尝试手动使用aspnet_compile收到以下消息：

无法加载文件或程序集'file：/// C：\\ Windows \\ Microsoft.NET \\ Framework64 \\ v4.0.30319 \\ Temporary ASP.NET Files \\ root \\ 6b69372f \\ fdfe0d46 \\ App_GlobalResources.melxzfvs.dll'或其依赖项之一。 试图加载格式错误的程序。

为了解决该问题，我尝试了以下操作：

• 清除存在该dll的ASP.NET临时文件
• 运行aspnet_regiis -i （64位版本）
• 将项目配置设置为x64而不是“任何CPU”

在Teleele JustDecompile之类的工具中查看App_GlobalResources dll表示该dll是专门为x86平台编译的，即使显然正在运行64位版本的aspnet_compile 。 bin文件夹中的所有其他程序集均为“任何CPU”。

我该怎么做才能针对x64进行编译？

编辑：如果我删除App_GlobalResources文件夹，则ASP.NET编译器将继续抱怨，除非现在它与App_Code.dll有关。 同样的问题。

Answer 1

在对.csproj和Web.config文件进行一些乏味的并行比较之后，我确定web.config中的以下部分是罪魁祸首：

  <system.codedom>
    <compilers>
      <compiler language="c#;cs;csharp" extension=".cs" type="Microsoft.CSharp.CSharpCodeProvider, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" compilerOptions="/unsafe /platform:x86" warningLevel="1">
        <providerOption name="CompilerVersion" value="v4.0" />
        <providerOption name="WarnAsError" value="false" />
      </compiler>
    </compilers>
  </system.codedom>

删除此部分后，将为“任何CPU”编译App_Code，App_GlobalResources及其同类。