add-migration provoque une erreur "Could not load assembly" (Impossible de charger l'assemblage)

Question

Voici ce que je recherche

PM> Add-Migration AddedSubdivion -StartUpProjectName Data -Verbose
Using StartUp project 'Data'.
Using NuGet project 'Registry'.
Could not load assembly 'Registry'. (If you are using Code First Migrations inside 
Visual Studio this can happen if the startUp project for your solution does not 
reference the project that contains your migrations. You can either change the startUp 
project for your solution or use the -StartUpProjectName parameter.)

Je n'ai aucune idée de la raison pour laquelle il essaie de faire référence à la Registry projet. Registry dépend de Data et non l'inverse. Je suis très novice en la matière, alors j'apprécierais toute aide.

Answer 1

C'est embarrassant, mais peut-être que cela aidera un googleur dans le futur.

En haut de la "Package Manager Console", mon projet par défaut était défini sur le mauvais projet. Je l'ai remplacé par mon projet modèle.

Answer 2

Le problème n'est peut-être pas si évident si vous avez Package Manager Console arrimé avec une fenêtre étroite... cachant le projet par défaut.

Il a besoin d'un large amarrage.

Answer 3

Cela peut également être dû à un décalage de plate-forme entre .NET Core et votre projet. Vous obtenez l'erreur suivante :

Impossible de charger l'assemblage 'DataProject'. Assurez-vous qu'il est référencé par le projet de démarrage 'ProgramProject'.

même si vous avez spécifié des noms de projet et de projet de démarrage corrects. (Soit en utilisant les listes déroulantes dans VS et dans la console du gestionnaire de paquets, soit en utilisant la commande -project y -startupproject paramètres.)

Vous pouvez y remédier en passant à n'importe quel processeur au lieu de x86, ou vice-versa (ou peut-être à x64, etc.), mais vous devrez alors passer de l'un à l'autre à chaque fois que vous devrez apporter des modifications à votre modèle/DB.

Conformément à cette réponse vous pouvez résoudre ce problème en modifiant l'ordre des entrées de votre chemin d'accès .NET Core dans les variables d'environnement du système. Si vous obtenez cette erreur, cela signifie que le premier chemin d'accès au .NET Core est pour x64 mais que vous essayez d'apporter des modifications à votre projet x86, ou peut-être l'inverse. Déplacez celui que vous ciblez au-dessus de celui que vous ne ciblez pas, enregistrez, puis redémarrez Visual Studio.

Vous pouvez voir lequel est actuellement utilisé avec la commande dotnet --info .

(Notez que cela suppose que vous avez installé les deux. Vous pouvez aussi n'avoir installé qu'un seul d'entre eux, auquel cas vous devrez installer l'autre, puis vérifier l'ordre des entrées du PATH ; si le deuxième que vous avez installé est celui que vous voulez, alors vous devrez certainement changer l'ordre du PATH pour en faire celui utilisé par VS, puisque son entrée devrait être en bas).

Answer 4

Si tout échoue, il y a toujours la verbose drapeau ( -v ).

Une commande comme dotnet ef database update -v devrait aider à clarifier le problème ef fait face.

Dans mon cas, le problème provenait du fait qu'EntityFramework avait du mal à gérer le fait que la cible de ma plateforme avait été modifiée, passant de AnyCPU à x86 o x64 .

System.BadImageFormatException: Could not load file or assembly 'MyProject, Culture=neutral, PublicKeyToken=null'. An attempt was made to load a program with an incorrect format.

Changement temporaire de la cible de la plateforme en AnyCPU a bien fonctionné.

Answer 5

Assurez-vous que vous vous concentrez sur :

1- Les projets de démarrage sont UI (MVC, API, ... etc).

2- Le projet par défaut dans la console du gestionnaire de paquets est la place de (ApplicationDbContext).