Visual Studio 2010: Impossible de résoudre mscorlib pour le framework cible '.NETFramework, Version = v4.0'
Nous migrons actuellement toutes nos solutions de 2005 à 2010 (c'est vrai, nous allons passer à 2008!). Nous sommes également en train de modifier la structure de nos fichiers pour donner un sens (certains projets communs seraient imbriqués dans des projets spécifiques, etc.).
Cela signifie que les références doivent être changées! En dehors de cela, nous les configurons tous en .NET 4.0. Pour ce faire, nous avons créé une solution temporaire "GOD" avec les 117 projets de la même solution.
Je le fais avec un collègue et jusqu'à il y a environ 2 heures, tout se déroulait comme prévu. Cependant, nous avons rencontré un problème avec l'un des 117 projets. Ce projet refuse "d'afficher" ses onglets de références, de ressources, de services et de paramètres dans les propriétés du projet.
Je reçois le message exact suivant:
Impossible de résoudre mscorlib pour la cible cadre ".NETFramework, Version = v4.0". Cela peut se produire si le cadre cible n'est pas installé ou si le nom de cadre est mal formaté.
Maintenant, c'est agaçant, mais la situation empire. Mon collègue, en obtenant la même solution de Subversion, PEUT réellement voir et changer les références et les choses. En fait, le projet est actuellement CONSTRUIT sur sa machine. Il a validé les modifications, mais je ne peux pas construire ce projet spécifique ni voir les références.
Ce qui m'amène à la conclusion simple: quelque chose doit être différent chez mon client, ce qui pose problème! Les suggestions en ligne que j'ai vues sont les suivantes:
- Plusieurs versions de .NET4.0 installées (ce n'est pas le cas sur mon client)
- .NET v3.5 n'est pas installé; v4.0 essaie de construire v3.5 (3.5 est installé sur mon client)
- La clé de registre: OnlyUseLatestCLR est définie et gâche tout! (scanné mon registre, cette clé n’est présente nulle part!)
Voir: http://connect.Microsoft.com/VisualStudio/feedback/details/542789/
La seule chose que je n’ai pas encore essayée, c’est de réparer .NET 4.0, mais je doute fort que ce soit le problème puisque nous avons environ 100 autres projets que je peux éditer et construire parfaitement. C # et VB.NET.
Microsoft Visual Basic pour Extensibility Applications 5.3 (VBIDE) est le nom du diable !!!
Apparemment, c'est une référence que mon collègue avait en quelque sorte, mais je ne l'ai pas fait et à cause de cette référence, TOUT est mort. Nous avons découvert cela parce que si vous cochez la case "Afficher tous les fichiers" du projet spécifique (qui est un projet VB.NET), vous obtenez le dossier "Références", qui n'est normalement pas présent pour le projet VB.Net, semble-t-il. Là où l'onglet nous a échoué, le dossier nous a montré une référence avec un avertissement. Apparemment, c’est quelque chose que le compilateur ou le VS2010 n’a pas pu me dire, mais c’est exactement ce qui nous a gâché.
Donc, si vous rencontrez cette erreur lorsque vous travaillez sur un projet, "Afficher tous les fichiers" pour voir le dossier Références et découvrir quelle référence pourrait être à l'origine de vos problèmes!
Je suis content qu'il ait trouvé ça après plus de 3 heures !! >. <
Il se peut que le chemin vers votre solution soit trop long:
Sens:
C:\MyProject\Folder\SubFolder ...
devrait être sous "256 Caractère".
http://wcfvs.blogspot.com/2011/04/could-not-resolve-mscorlib-for-target.html
J'ai trouvé ce fil lorsque j'ai eu le même problème, mais aucun problème de référence. J'ai trouvé le lien ci-dessus et cela a résolu mon problème. J'espère que cela aidera quelqu'un d'autre qui vient ici avec le même problème.
Je recevais cette erreur Avertissement juste ce matin. Je viens de reconstruire le projet, puis j'ai fermé Visual Studio, je l'ai rouvert et l'erreur a disparu.
j'ai travaillé sur mon projet enregistré le travail et fermé visual studio 2010. lorsqu’il a été ouvert à nouveau pour travailler j’ai eu cette erreur je viens de fermer visual studio à nouveau copié le fichier où mon projet a été enregistré et je l’ai collé ailleurs (dans un fichier sur mon bureau ) et j’ai rouvert le projet avec VS2010 et cela fonctionnait.
J'ai eu ce problème aujourd'hui et la solution a été d'éditer manuellement le fichier Resources.resx .
Mon fichier Resources.resx ressemblait à ceci:
<data name="SomeString" xml:space="preserve">
<value>I am a string</value>
</data>
<Assembly alias="System.Windows.Forms" name="System.Windows.Forms, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
<data name="MyLogo" type="System.Resources.ResXFileRef, System.Windows.Forms">
<value>..\Resources\MyLogo.png;System.Drawing.Bitmap, System.Drawing, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a</value>
</data>
<data name="Open" type="System.Resources.ResXFileRef, System.Windows.Forms">
<value>..\Resources\Open.png;System.Drawing.Bitmap, System.Drawing, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a</value>
</data>
Il s'est avéré que Visual Studio n'aimait pas les deux éléments <data> après l'élément <Assembly>, ce qui est étrange compte tenu du fait que Visual Studio les a ajoutés eux-mêmes. Mon problème a été résolu après que je les ai déplacés avant l'élément <Assembly>:
<data name="SomeString" xml:space="preserve">
<value>I am a string</value>
</data>
<data name="MyLogo" type="System.Resources.ResXFileRef, System.Windows.Forms">
<value>..\Resources\MyLogo.png;System.Drawing.Bitmap, System.Drawing, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a</value>
</data>
<data name="Open" type="System.Resources.ResXFileRef, System.Windows.Forms">
<value>..\Resources\Open.png;System.Drawing.Bitmap, System.Drawing, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a</value>
</data>
<Assembly alias="System.Windows.Forms" name="System.Windows.Forms, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
J'ai eu le même problème et après avoir essayé la plupart de ce qui précède, y compris la réinstallation de .NET 4.0 et le redémarrage, ne sont toujours pas partis.
Finalement résolu en déplaçant mon arbre de projet plus bas. c'est à dire. plus proche de la racine du lecteur. Le répertoire et les noms de fichiers étaient trop longs et je pense que les références étaient tronquées et ne pouvaient donc pas être résolues.
Le problème est venu tout de suite.
M'est arrivé dans l'éditeur de ressources.
Cause: J'importais un fichier .Targets, qui définissait une propriété appelée AppConfigFile, qui remplaçait probablement une propriété interne du même nom:
<PropertyGroup>
<AppConfigFile>...</AppConfigFile>
</PropertyGroup>
Correction: la propriété renommée en un autre nom, et le problème a disparu.
J'ai eu ce problème dans Visual Studio 2013 lors du passage de .NET 4.5 à .NET 4.6.2. Le projet de problème était un projet de site Web.
Visual Studio exécute automatiquement un outil qui génère Reference.svcmap. Le Reference.cs commence par:
//------------------------------------------------------------------------------
// <auto-generated>
// This code was generated by a tool.
// Runtime Version:4.0.30319.42000
//
// Changes to this file may cause incorrect behavior and will be lost if
// the code is regenerated.
// </auto-generated>
//------------------------------------------------------------------------------
Le simple choix de la nouvelle version .NET a obligé Visual Studio à nettoyer les fichiers générés et à ne pas remplir le contenu. J'ai essayé toutes les solutions ci-dessus mais aucune n'a fonctionné. Finalement, j'ai choisi .NET 4.5.1 suivi de .NET 4.6.2 et l'outil s'est exécuté. La différence dans les fichiers était seulement le numéro de version de l'outil qui était dans un commentaire, donc j'aurais pu récupérer les fichiers de GIT.
J'ai eu le même problème avec une référence de service (Web) dans mon projet. " Mettre à jour la référence de service " et " Configurer la référence de service " ne fonctionnait plus.
Eh bien, jetons simplement la référence de service (Web) et créez-la à nouveau. Ne pas aller! Même message d'erreur.
Solution: modifiez le fichier de projet et supprimez tout ce qui concerne les références de service.
Instructions:
- Allez dans l'explorateur de solutions et cliquez avec le bouton droit de la souris sur le nom du projet et sélectionnez le fichier "Décharger le projet".
- Accédez à l'explorateur de solutions, cliquez avec le bouton droit de la souris sur le nom du projet et sélectionnez "Modifier votre nom de projet.proj".
- Supprimer chaque élément ayant quelque chose à voir avec vos références de service (Web). (En général, il contient du texte "références de service")
- Allez dans l'explorateur de solutions et cliquez avec le bouton droit de la souris sur le nom du projet et sur le __.sélectionner "Recharger le projet".
- Maintenant, ajoutez à nouveau vos références de service (Web).
Problème résolu (bon c'était dans mon cas).
Je devine ce qui aurait pu se passer: j'ai changé de classe quelque part dans mon service Web. L'interface n'a pas été modifiée et Visual Studio ne voit pas les modifications. La configuration (mise en cache?) Ne correspond plus et la configuration/reconstruction/suppression du service (Web) échoue.
J'étais en train de migrer un projet vb.net vers VS 2015. J'avais également le même problème. Le problème ne vient pas du framework .Net, car j'ai pu créer un nouveau projet ciblant les versions du framework spécifiques et cela a réussi.
Dans mon cas, le projet faisait référence à FPSpreadADO et à d'autres bibliothèques similaires. Cela a bien fonctionné une fois que j'ai supprimé ces références.
pour moi, le simple fait de configurer Target Framework 4.0 a résolu mon problème. Parfois, le cadre cible est clair d'une manière ou d'une autre. Cela pourrait causer un problème.
Vérifiez que le cadre cible dans les propriétés du projet est défini correctement (par défaut, il s'agit du "client .Net Framework 4.0"). Il se peut que vous ayez besoin de ".Net Framework 4.0"
voir ce fil qui ressemble au même problème
vous voudrez peut-être aussi passer en revue cet article qui concerne le débogage d'un problème présentant le même symptôme à l'aide d'un réflecteur
J'ai eu une erreur similaire dans le projet PCL XamarinForms.
J'ai découvert que l'erreur concernait une référence du projet. J'ai mis à jour xamarin.forms avec la dernière version et pour certaines raisons, NuGet n'a pas été en mesure de supprimer toutes les références de la version précédente du fichier de projet (xml).
Donc, j'ai simplement supprimé la ligne suivante du fichier de projet et cela a fonctionné!
<Error Condition="!Exists('..\..\packages\Xamarin.Forms.2.3.1.114\build\portable-win+net45+wp80+win81+wpa81+MonoAndroid10+MonoTouch10+Xamarin.iOS10\Xamarin.Forms.targets')" Text="$([System.String]::Format('$(ErrorText)', '..\..\packages\Xamarin.Forms.2.3.1.114\build\portable-win+net45+wp80+win81+wpa81+MonoAndroid10+MonoTouch10+Xamarin.iOS10\Xamarin.Forms.targets'))" />
J'espère que ça aide quelqu'un ...
Dans la plupart des cas, c'est dû à une référence manquante.
Dans la solution Explorer -> Référence -> vous pouvez voir la référence manquante (en jaune) Ajoutez simplement la référence, vous irez bien.
J'ai rencontré ce problème aujourd'hui et cela a été causé par des noms de fichiers trop longs dans le projet.
Ceci, à son tour, a été causé par certaines références de service . Lorsqu'une référence de service est importée ou mise à jour, visual studio génère des fichiers .datasource, où le nom de fichier est le nom complet. Cela signifie des noms très longs dans certains cas.
En cherchant sur Google, j'ai trouvé des indices qu'il était prudent de supprimer ces fichiers . Vérifiez ceci ou ceci out.
La suppression de ces fichiers .datasource a résolu le problème.
Ce qui m'est arrivé, c’est que toutes mes références sur mon projet ont été perdues, il a donc fallu que je les insère à nouveau.
J'ai rencontré ce problème aujourd'hui dans Visual Studio 2017 sur un projet que j'avais apparemment commencé en tant qu'application de la plate-forme Windows universelle, mais que j'avais finalement opté pour une application de bureau Windows Forms.
D'une manière ou d'une autre, soit par une erreur de branche, soit par un problème de validation dans le contrôle de code source, certains fichiers UWP XAML obsolètes/ignorés, ainsi qu'un fichier "project.json", ont été replacés dans mon dossier de projet. VS ne créerait plus et ne lirait plus mon application Windows Forms avec une erreur similaire à celle signalée par d'autres ci-dessus (par exemple, "Impossible de résoudre mscorlib pour le cadre cible '.NETFramework, Version = v4.7'").
Après la suppression de tous les fichiers UWP obsolètes (y compris "project.json", tous les fichiers XAML et toute autre fausse note connexe) du dossier de projet et du rechargement de la solution, les erreurs ont disparu et le projet a été construit et lancé avec succès.
J'espère que cela t'aides.
J'ai aussi cette erreur. ("Impossible de résoudre mscorlib pour le framework cible '.NetFramework 4.5.1'. Cela peut arriver si le framework cible n'est pas installé ou si le moniker de framework est mal formaté.").
Cela s'est produit lorsque j'ai modifié la structure de 3.5 en 4.5.1 sur un projet VB 2013 . La solution consistait à supprimer toutes les références du fichier .vbproj: toutes les références intitulées Groupes de référence et COMReference.
Bien sûr, juste après avoir fait cela, toutes sortes d’erreurs sont apparues dans le projet.
Ensuite, j'ai commencé à les recopier, un à un au même endroit, en les copiant à partir d'une copie de sauvegarde afin d'identifier celles qui posaient problème (j'ai copié celles qui étaient liées aux nouvelles erreurs que j'avais commises pour les corriger). ), en actualisant le projet à chaque fois jusqu'à ce que la fenêtre concernée soit visualisée correctement.
Il en résulta que c'étaient des références de bibliothèques personnalisées qui avaient créé ce problème . J'espère que cela pourrait aider quelqu'un .
Un développeur.
Couru dans cette aujourd'hui.
Dossiers bin & obj supprimés.
Ré-ouvert Visual Studio et ça a soudainement fonctionné.
J'ai eu le même problème lorsque le répertoire source était en lecture seule. Si je synchronise mon espace de travail avec notre serveur de contrôle de version (Perforce), tous les répertoires seront lus uniquement par défaut, à moins que je ne sélectionne mon extraction du répertoire. Parfois, je suis paresseux et je ne le fais pas car je suis la seule personne à travailler sur certains de ces projets à un moment donné. Mais cette erreur disparaît, effacez le drapeau lecture seule.