Je prépare une toute nouvelle solution ASP.NET MVC 5.1. J'ajoute un paquet de paquets NuGet et le configure avec Zurb Foundation, etc.
Dans ce cadre, j'ai ajouté une référence à un package NuGet interne, qui est une bibliothèque de classes portable, ce qui pose un problème sur le serveur de génération.
TeamCity échoue à la construction avec:
Le type 'System.Object' est défini dans un assembly qui n'est pas référencé. Vous devez ajouter une référence à Assembly 'System.Runtime, Version = 4.0.0.0.
A l'origine, j'avais ajouté le correctif pour une erreur identique ou similaire lors de la compilation des pages Web de Razor, ce correctif étant dans le web.config
<compilation ... >
<assemblies>
<add Assembly="System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
</assemblies>
</compilation>
Cependant, le problème n'est pas résolu.
L'ajout d'une référence à cet ensemble System.Runtime.dll a résolu le problème suivant:
C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5.1\Facades\System.Runtime.dll
Bien que ce fichier dans ce chemin explicite n'existe pas sur le serveur de construction.
Je posterai avec plus d'informations une fois que j'aurai trouvé de la documentation sur PCL et ces façades.
Mettre à jour
Oui, à peu près rien sur les assemblages de façades sur Internet.
Google:
(Facades OR Facade) Portable Library site:Microsoft.com
Pour implémenter le correctif, développez d'abord la section de compilation web.config existante qui ressemble à ceci par défaut:
<compilation debug="true" targetFramework="4.5"/>
Une fois développé, j'ai ensuite ajouté le nouveau XML de configuration suivant les instructions qui m'ont été données:
<assemblies>
<add Assembly="System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
</assemblies>
Les balises web.config finales devraient ressembler à ceci:
<compilation debug="true" targetFramework="4.5">
<assemblies>
<add Assembly="System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
</assemblies>
</compilation>
Le commentaire de @ PeterMajeed dans la réponse acceptée m'a aidé à résoudre un problème connexe. Je n'utilise pas la bibliothèque portable, mais j'ai la même erreur de compilation que lors d'une nouvelle installation de Windows Server 2012, où j'exécute TeamCity.
L'installation de Microsoft .NET Framework 4.5.1 Developer Pack a résolu le problème (après avoir installé séparément les MS Build Tools ).
La seule façon qui a fonctionné pour moi. Ajouter l'assembly à web.config
<compilation debug="true" targetFramework="4.5">
<assemblies>
<add Assembly="System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
</assemblies>
</compilation>
J'ai eu ce problème dans certaines solutions sur VS 2015 (pas MVC cependant), et même dans la même solution sur un poste de travail mais pas sur un autre. Les erreurs commencées sont apparues après le passage de la version .NET à la version 4.6 et la référence à PCL.
La solution est simple: Fermez la solution et supprimez le dossier .vs masqué dans le même dossier que la solution.
L'ajout des références manquantes comme suggéré dans d'autres réponses résout également le problème, mais l'erreur reste résolue même après que vous ayez à nouveau supprimé les références.
En ce qui concerne TeamCity, je ne saurais le dire car ma configuration n’a jamais posé de problème. Mais assurez-vous de réinitialiser le catalogue de travail dans le cadre de vos efforts de débogage.
Installez le .NET Runtime ainsi que le pack de ciblage pour la version .NET que vous ciblez.
Le pack de développeurs regroupe ces deux éléments mais, à ce jour, il ne semble pas avoir de version 4.6, vous devez donc installer les deux éléments séparément.
Les téléchargements peuvent être trouvés ici: http://blogs.msdn.com/b/dotnet/p/dotnet_sdks.aspx#
C'est un vieux problème, mais j'y ai fait face aujourd'hui afin de réparer un pipeline de build sur notre serveur d'intégration continue. Ajouter
<Reference Include="System.Runtime" />
à mon fichier .csproj
résolu le problème pour moi.
Un peu de contexte: le projet intéressé est un projet complet .NET Framework 4.6.1, sans problème de construction sur les machines de développement. Le problème qui apparaît uniquement sur le serveur de génération, que nous ne pouvons pas contrôler, peut être dû à une version différente du SDK ou à un logiciel similaire.
L'ajout du <Reference
proposé a résolu l'erreur de construction, au prix d'une référence manquante warning (triangle jaune sur l'entrée ajoutée dans l'arborescence des références) dans Visual Studio.
J'espère que cela peut aider les gens dans des scénarios similaires ...
Je devais télécharger et installer le SDK Windows 8.0 (et non 8.1) pour que l'erreur disparaisse sur mon serveur TeamCity.
https://developer.Microsoft.com/en-us/windows/downloads/windows-8-sdk
j'ai ajouté System.Runtime.dll au projet bin et cela a fonctionné :)
J'ai eu la même erreur sur notre serveur de compilation Tfs 2013, dans un projet de test . Avec le projet Web principal s'exécutant sur .Net 4.5.1.
J'ai installé un paquet nuGet de System Runtime et ajouté la référence de Packages\System.Runtime.4.3.0\ref\net462\System.Runtime.dll
Cela l'a résolu pour moi.
J'ai eu ce problème dans une solution avec un projet Web API et plusieurs projets de bibliothèque. L'un des projets de la bibliothèque était en train de bouger lors de la construction, avec des erreurs disant que les attributs de Unity n'étaient pas des attributs "valides", et qu'une erreur disait que je devais faire référence à System.Runtime.
Après de nombreuses recherches, la réinstallation du pack de développement 4.5.2 et aucun résultat, je me suis dit que ce n'était peut-être pas une correspondance de version. J'ai donc examiné les propriétés de chaque projet et l'une des bibliothèques de base visait la version 4.5, tandis que toutes les autres visaient la version 4.5.2. J'ai changé celui-ci pour cibler également 4.5.2 et les erreurs sont parties.
Je faisais également face à ce problème lorsque je tentais de lancer un projet ASP .NET MVC après une mise à jour mineure de notre base de code, même s’il avait été compilé sans erreur:
Message d'erreur du compilateur: CS0012: le type 'System.Object' est défini dans un assembly qui n'est pas référencé. Vous devez ajouter une référence à Assembly 'System.Runtime, Version = 4.0.0.0, Culture = neutre, PublicKeyToken = b03f5f7f11d50a3a'.
Notre projet n’avait jamais rencontré ce problème et j’étais sceptique quant à la modification des fichiers de configuration avant de trouver la cause. A partir des journaux d'erreurs, j'ai pu localiser cette sortie détaillée du compilateur qui indiquait ce qui se passait réellement:
warning CS1685: Le type prédéfini 'System.Runtime.CompilerServices.ExtensionAttribute' est défini dans plusieurs assemblys de l'alias global. en utilisant la définition de 'c:\Windows\Microsoft.NET\Framework64\v4.0.30319\mscorlib.dll'
c:\Utilisateurs\Admin\Développement de logiciel\source-control\Binaries\Publier\WebApp\Vues\Compte\Index.cshtml (35,20): erreur CS0012: le type 'System.Object' est défini dans un assembly qui est non référencé. Vous devez ajouter une référence à Assembly 'System.Runtime, Version = 4.0.0.0, Culture = neutre, PublicKeyToken = b03f5f7f11d50a3a'.
c:\Windows\Microsoft.NET\Framework64\v4.0.30319\Fichiers ASP.NET temporaires\meseems.webapp\68e2ea0f\8c5ee951\Assembly\dl3\52ad4dac\84698469_3bb3d401\System.Collections.Immutable.DLL: (emplacement du symbole lié) à l'erreur précédente)
Apparemment, un nouveau package ajouté à notre projet faisait référence à une version plus ancienne du .NET Framework, ce qui provoquait le problème de "définition dans plusieurs assemblys" (CS1685), qui entraînait une erreur du compilateur de vue rasoir au moment de l'exécution.
J'ai supprimé le package incompatible (System.Collections.Immutable.dll) et le problème a cessé de se produire. Cependant, si le paquet ne peut pas être supprimé dans votre projet, vous devrez essayer Réponse de Baahubali .
Je copie le fichier "C:\Program Files (x86)\Assemblys de référence\Microsoft\Framework.NETFramework\v4.5.1\Façades\system.runtime.dll" dans le dossier bin du serveur de production, cela résout le problème.