2013-03-04 6 views
5

Wir haben den scheinbar häufigen FehlerCompile .net 4.0-Projekt auf Build-Server mit .net 4.5

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

in einem Projekt, das gegen .NET 4.0 kompiliert werden muss, sondern auf einem Build-Server ausgeführt wird gebaut Windows Server 2012 (mit .Net 4.5). Bei dem Projekt handelt es sich um eine Webanwendung, die auf einem Webserver 2003 ausgeführt wird, auf dem die Installation von .Net 4.5 nicht möglich ist. Es läuft es gegen „klassische“ .Net 4.0

Aus ähnlichen Fragen sind wir Befehlszeilenoptionen zu MSBuild versuchen:

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

Wir haben auch verschiedene Kombinationen von

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

Die Referenz-Assemblys (einschließlich der DLL-Dateien) sind tatsächlich an dieser Stelle auf dem Build-Server installiert. Aber wenn wir die Website bereitstellen und die Homepage besuchen, erhalten wir diesen Fehler. (Interessanterweise verschwindet der Fehler beim Neuladen einer Seite und die Site wird normal ausgeführt.) Welche MSBuild-Parameter sind für die Kompilierung mit den .NET 4.0-Assemblys erforderlich?

aktualisieren schaltete ich lächerlich Ebene Protokollierung auf MSBuild, und ich sehe, dass offenbar wird es gegen die 4.0 Referenz Baugruppen .Net Aufbau:

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

und ich sehe es noch keine Erwähnung Assemblys außerhalb dieses Ordners oder des Arbeitsverzeichnisses des Buildservers. Es scheint also korrekt zu kompilieren, aber wenn es auf dem Webserver bereitgestellt wird, löst es die Ausnahme aus.

In Bezug auf die Ausnahme auf einer Seite neu zu laden, frage ich mich, ob das mit dem Markup vor der Kompilierung Schritt verbunden ist. Wir führen aspnet_compile auf dem Build-Server aus. Wenn eine Ausnahme von einer generierten Assembly kommt, wird der Webserver sie erneut kompilieren. Und die neu kompilierte Assembly ist in Ordnung, weil sie mit True .Net 4.0 erstellt wurde.

+0

Verwenden Sie ILMerge? –

+0

Wir verwenden ILMerge nicht. –

+0

Benennen Sie C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ mscorlib.dll auf diesem Buildserver um und führen Sie einen sauberen Build durch. Sie finden das Projekt, das die falschen Referenzassemblys verwendet. –

Antwort

3

Nun, die Antwort erwies sich als grenzwertig peinlich. Nachdem wir anhand der detaillierten MSBuild-Ausgabe bestätigt hatten, dass das Website-Projekt tatsächlich mit den richtigen Referenzbaugruppen erstellt wurde, stellten wir fest, dass es in dem Projekt mehrere interne NuGet-Pakete gab, die mit .Net 4.5 erstellt wurden. Einer von ihnen war randvoll mit Erweiterungsmethoden, was die Ausnahme verursacht. Der Wiederaufbau gegen .Net 4.0 behob das Problem.

Was bringt ein interessantes Thema. Wenn ein NuGet-Paket von Drittanbietern für 4.0 kompiliert wird, aber 4.5 Referenzen verwendet, befinden wir uns in der gleichen Situation, können es aber nicht beheben. Die Lektion für Paket-Publisher besteht also darin, sicherzustellen, dass Ihre Version 4.0 mit den Referenz-Assemblys kompiliert wird.