L’espace de noms XML par défaut du projet doit être l’espace de noms XML MSBuild

J’ai cloné localement le Repo SignalR d’ASP.NET Core et essayé d’ouvrir la solution dans l’environnement suivant.

IDE

Microsoft Visual Studio Enterprise 2015 Version 14.0.25431.01 Update 3 Microsoft .NET Framework Version 4.6.01055 

DOT NET CLI

 λ dotnet --info .NET Command Line Tools (1.0.0-preview2-1-003177) Product Information: Version: 1.0.0-preview2-1-003177 Commit SHA-1 hash: a2df9c2576 Runtime Environment: OS Name: Windows OS Version: 6.1.7601 OS Platform: Windows RID: win7-x64 

Je finis par voir beaucoup de ces types de messages d’erreur:

..\Repos\SignalR\src\Microsoft.AspNetCore.SignalR\Microsoft.AspNetCore.SignalR.csproj : erreur: l’espace de noms XML par défaut du projet doit être l’espace de noms XML MSBuild. Si le projet est créé au format MSBuild 2003, ajoutez xmlns="http://schemas.microsoft.com/developer/msbuild/2003" à l’élément. Si le projet a été créé dans l’ancien format 1.0 ou 1.2, convertissez-le au format MSBuild 2003. ..\Repos\SignalR\src\Microsoft.AspNetCore.SignalR\Microsoft.AspNetCore.SignalR.csproj

Je veux savoir comment corriger cela correctement.

Les projets que vous essayez d’ouvrir se trouvent dans le nouveau format .Net Core csproj. Cela signifie que vous devez utiliser Visual Studio 2017 qui prend en charge ce nouveau format.

Pour un peu d’histoire, initialement .Net Core a utilisé project.json au lieu de *.csproj . Cependant, après de csproj délibérations internes chez Microsoft, ils ont décidé de revenir à csproj mais avec un format beaucoup plus propre et mis à jour. Cependant, ce nouveau format est uniquement pris en charge dans VS2017.

Si vous souhaitez ouvrir les projets sans attendre le 7 mars pour la version officielle de VS2017, vous pouvez utiliser Visual Studio Code à la place.

J’ai rencontré ce problème lors de l’ouverture de l’application Service Fabric GettingStartedApplication dans Visual Studio 2015. La solution d’origine a été créée sur .NET Core dans VS 2017 et j’ai eu la même erreur lors de son ouverture en 2015.

Voici les étapes que j’ai suivies pour résoudre le problème.

  • Cliquez avec le bouton droit sur le projet (load Failed) et modifiez-le dans Visual Studio.
  • Vu la ligne suivante dans la balise Project:

  • Suivez les instructions affichées dans le message d’erreur pour append xmlns="http://schemas.microsoft.com/developer/msbuild/2003" à cette balise

Il devrait maintenant ressembler à:

  
  • Le rechargement du projet m’a donné la prochaine erreur (la vôtre peut être différente selon ce qui est inclus dans votre projet)

L'élément n’est pas reconnu”>

  • Vu que l’élément None avait un atsortingbut de mise à jour comme ci-dessous:

      PreserveNewest  
  • Commenté comme ci-dessous.

      
  • Sur l’erreur suivante: la version dans la référence du package n’est pas reconnue La version dans l'élément <PackageReference/> n’est pas reconnue”> </p>
</li>
<li>
<p>  Vu que la version est présente dans csproj xml comme ci-dessous (lignes de PackageReference supplémentaires supprimées pour des raisons de concision) </p>
</p>
</li>
<li>
<p>  Supprimé l’atsortingbut Version </p>
<pre> <code><packagereference Include=

  • Je reçois maintenant ce qui suit: Mise à niveau automatique VS

Bingo! La mise à niveau one-way de Visual Studio a démarré! Laissez VS faire la magie!

  • Le projet chargé mais avec des erreurs de référence lib. entrer la description de l'image ici

  • Correction des erreurs de référence libérées individuellement en supprimant et en remplaçant NuGet pour que le projet fonctionne!

J’espère que cela aide un autre voyageur de code 😀

La réponse de @ DavidG est correcte, mais j’aimerais append que si vous construisez à partir de la ligne de commande, la solution équivalente consiste à vous assurer que vous utilisez la version appropriée de msbuild (dans ce cas particulier, il faut version 15).

Exécuter msbuild /? pour voir quelle version vous utilisez ou where msbuild pour vérifier quel emplacement l’environnement prend l’exécutable et mettre à jour (ou pointez vers le bon emplacement de) les outils si nécessaire.

Téléchargez le dernier outil MSBuild ici .

Si vous obtenez cette erreur en essayant de créer l’application .Net Core 2.0 sur VSTS, assurez-vous que votre définition de génération utilise la queue de l’agent Hosted VS2017 .