6
votes

Obtention de «NETSDK1045 Le SDK .NET actuel ne prend pas en charge .NET Core 3.0 en tant que cible» lors de l'utilisation du modèle hébergé Blazor Asp.NetCore

J'ai installé l'aperçu de .NetCore 3.0 et essayé d'exécuter le modèle Blazor Blazor (hébergé par ASP.NET Core) dans Visual Studio 2019:

 entrez la description de l'image ici

L'erreur qui s'est produite était la suivante:

NETSDK1045 Le SDK .NET actuel ne prend pas en charge .NET Core 3.0 en tant que cible. Ciblez .NET Core 2.2 ou version antérieure ou utilisez une version du SDK .NET prenant en charge .NET Core 3.0.


0 commentaires

7 Réponses :


7
votes

Suite au commentaire sous https://github.com/dotnet/cli/ issues / 8743 # issuecomment-371519751 , j'ai réussi à résoudre le problème en installant la version x86 du .NET Core 3.0 en plus de la version x64. La compilation a fonctionné après le redémarrage de Visual Studio (2019).


0 commentaires

0
votes

J'ai eu la même erreur et je l'ai résolue en cochant l'option "Utiliser les aperçus du SDK .NET Core (nécessite un redémarrage)". Ouvrez Outils> Options et essayez de regarder «Fonctionnalités de prévisualisation» ou «.Net Core» en fonction de votre version de Visual Studio. Attention aux mises à jour VS, ils peuvent le désactiver.


0 commentaires

10
votes

Au cours de ces jours, j'ai dû surmonter ce problème sur un certain nombre de machines / conteneurs de développement différents: finalement, j'ai trouvé pas moins de 6 raisons différentes qui pouvaient provoquer ce genre d'erreur:

  1. SDK .NET Core 3 manquant (x86 ou x64)
  2. Prise en charge de l'aperçu du SDK .NET Core non activée dans VS2019
  3. VS2017 au lieu de VS2019
  4. Chemin du SDK incorrect dans la ou les variables d'environnement PATH
  5. Chemin du SDK incorrect dans la ou les variables d'environnement MSBuildSDKsPath
  6. Mauvaise version du SDK dans le fichier global.json du projet

Les solutions de contournement pour ces scénarios sont assez faciles à comprendre, vous devez essentiellement soit installer le SDK approprié, soit supprimer la ou les références SDK «offensantes». Cependant, j'ai fait de mon mieux pour les documenter tous dans ce post sur mon blog.


3 commentaires

Bingo. Même si l'erreur disait que je n'avais pas 3.1, l'erreur réelle était que global.json était toujours explicitement nommé 3.0.


J'ai vu votre blog avant d'arriver ici. Je rencontre ce problème sur le pipeline de build Azure.


Je rencontre également cela sur le pipeline de build Azure. Quelqu'un sait-il comment résoudre ce problème au mieux?



0
votes

C'est une solution très hacky mais au moins ça a marché. Disons que vous avez installé le SDK pour 3.0.100-rc1-014190. Il apparaît dans dotnet --list-sdks comme prévu mais ne semble toujours pas être détecté par Visual Studio, et vous obtenez la même erreur NETSDK1405 lorsque vous essayez de créer ou de tester quoi que ce soit à partir de l'interface de ligne de commande dotnet .

Recherchez dans le répertoire d'installation de dotnet SDK (généralement C: \ Program Files \ dotnet \ sdk ). Vous devriez y voir votre SDK d'aperçu. Créez une copie ou renommez le dossier existant pour supprimer le suffixe de la version d'aperçu. Par exemple, 3.0.100-rc1-014190 deviendrait à la place 3.0.100 , comme ceci:

 entrez la description de l'image ici

En faisant cela, la prise en charge de la préversion .Net Core 3 fonctionnait enfin dans VS2019 Preview 4 et la CLI dotnet pour moi.


0 commentaires

0
votes

Pour moi, c'était aussi simple que d'activer l'aperçu dans Visual Studio 2019. Malheureusement, la plupart des articles qui montrent comment faire cela sont, je pense, obsolètes. Je suis finalement tombé sur ce post de débordement de pile Comment l'activer. NET Core 3 preview SDK dans VS2019? Ils ont déplacé la case à cocher et ce n'était pas activé par défaut pour moi.


0 commentaires

0
votes

Ce fut un problème frustrant à localiser et après avoir effectué toutes les mises à jour de VS sans pouvoir toujours l'installer, je l'ai retracé dans une variable d'environnement. Essayez de supprimer MSBuildSDKsPath et voyez si cela résout votre problème.


0 commentaires

1
votes

Pour moi, la solution consistait à supprimer une variable de chemin MSBuildSDKsPath - En raison de l'exploration de l'aperçu, i de sdks a déclaré à un moment donné cette variable pour corriger un autre bogue de sdk - il semble que la force définit la version utilisée. Donc, dans mon cas, il a été défini sur 3.0.100 et a entraîné des erreurs lors de la tentative d'utilisation de 3.1.300


0 commentaires