Question

我们遇到了看似常见的错误

Could not load type 'System.Runtime.CompilerServices.ExtensionAttribute' from assembly 'mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089

在一个项目中，需要针对.Net 4.0进行编译，但是构建在运行Windows Server 2012的构建服务器上（.Net 4.5）。该项目是一个Web应用程序，可部署到运行2003的Web服务器，其中安装.Net 4.5不是一个选项。在那里它运行“经典”.Net 4.0

从类似的问题，我们正在尝试MSBuild的命令行选项：

/property:FrameworkPathOverride="C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0"

我们还尝试了

的各种组合

/property:ReferencePath="C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0"
/property:NoStdLib=true
/property:NoCompilerStandardLib=true

参考程序集（包括.dll文件）实际上安装在构建服务器上的那个位置。但是当我们部署网站并访问主页时，我们会收到该错误。（有趣的是，在页面重新加载时，错误消失，站点正常运行。）编译.Net 4.0程序集所需的MSBuild参数是什么？

更新我在MSBuild上打开了荒谬的日志，我看到它显然是针对.Net 4.0参考程序集构建的：

Resolved file path is "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\mscorlib.dll

我没有看到该文件夹或构建服务器工作目录之外的程序集。因此它似乎可以正确编译，但是当部署在Web服务器上时，它会抛出异常。

关于页面重新加载的异常消失，我想知道这是否与标记预编译步骤有关。我们在构建服务器上运行aspnet_compile。也许如果生成的程序集有异常，Web服务器将重新编译它。重新编译的程序集很好，因为它是使用真正的.Net 4.0创建的。

Answer 1

答案结果证明是尴尬的边缘。在我们从详细的MSBuild输出确认它实际上是针对正确的参考组件构建网站项目之后，我们意识到项目中有几个内部NuGet包是针对.Net 4.5构建的。其中一个充满了扩展方法，这是造成异常的原因。针对.Net 4.0重建它们解决了这个问题。

这引出了一个有趣的问题。如果为4.0编译第三方NuGet包但使用4.5引用，我们将处于相同的情况，但无法修复它。因此，包发布者的教训是确保根据参考程序集编译4.0版本。

使用.net 4.5在构建服务器上编译.net 4.0项目

1 个答案: