J'ai mis à jour Visual Studio 2013 mise à jour 2 et je ne peux plus échafauder les contrôleurs.
Le problème n'est pas spécifique à un projet: lorsque j'essaie d'échafauder un contrôleur, l'erreur suivante s'affiche dans les projets ALL et ANY:
There was an error running the selected code generator:
'Exception has been thrown by the target of an invocation.'
Cela fonctionnait avant la mise à jour vers Visual Studio 2013 update 2.
Ont fouillé la question à mort, mais aucune des suggestions proposées ne fonctionne
Par exemple:
Commenter OnModelCreating dans mon contexte;
Suppression de packages tels que MvcScaffolding, etc. (je n’en ai aucun installé et cela ne fonctionne avec AUCUN projet);
J'ai modifié/personnalisé certains des modèles, mais cela fonctionnait après les modifications.
J'ai désinstallé Visual Studio 2013 Update 2 et suis ainsi revenu à Visual Studio version 12.0.21005.1 REL.
Le problème a disparu. Par conséquent, le problème est très clairement lié à la mise à jour 2.
Est-ce que quelqu'un (y compris Microsoft) connaît un correctif?
La réponse de Farruk Subhani ne répond pas à la question: la question indique clairement que la suppression des références à MVCScaffolding ne résout pas le problème.
J'ai ajouté une prime de 200 points, veuillez répondre à la question comme indiqué clairement.
Une combinaison de choses a fonctionné pour moi:
Mettre à niveau vers Visual Studio 2013 Update 3.
Mettre à niveau Entity Framework vers 6.1.1
Modifiez la configuration du contexte pour utiliser IDbSet <...> au lieu de DbSet <...> (j'ai entendu dire que cela peut affecter l'utilisation des actions async tel que fourni par l'exemple de package Nuget d'ASP.NET Identity 2).
Pourquoi cette combinaison fonctionne-t-elle, je n'en ai aucune idée. Mais ensuite, étant donné le silence étouffant de la SP, je ne suis probablement pas seul. Je suppose que la mise à jour 2 n'a tout simplement pas fonctionné ...
Hé pour vous tous que rien ne fonctionne, la vraie réponse est que vous devez supprimer tout ce qui a un configSource sur le web.config et la chaîne de connexion doit être en ligne.
MODIFIER:
Quelqu'un a fait remarquer que seules les balises <configSettings>
, <appSettings>
et <connectionStrings>
NE PAS utiliser d'attribut configSource doivent être utilisées. Et qu'il était toujours capable d'utiliser des attributs configSource ailleurs, tels que la balise rewriter.
Je pense que c'est que l'outillage ne peut pas suivre les emplacements configSource pour les éléments qu'il utilise tels que les chaînes de connexion et les paramètres d'application.
Microsoft devrait être sur ce problème s'il n'est pas encore résolu.
EDIT 2:
Même si @awrigley a marqué sa réponse comme correcte, c'est un bogue connu de Visual Studio. J'ai réussi à le savoir et je pense que cela va attirer l'attention bientôt . https://github.com/aspnet/Tooling/issues/169#issuecomment-144197015
Solution
Assurez-vous que la section
<connectionStrings>..</connectionStrings>
est après
<configSections>..</configSections>
Veuillez exécuter la commande suivante dans Package Manager Console :
Uninstall-Package EntityFramework -Force
Install-Package EntityFramework
Uninstall-Package MvcScaffolding
Install-Package MvcScaffolding
J'ai eu le même problème avec Visual Studio 2013 Update 3, mais uniquement pour les échafaudages travaillant avec Entity Framework . Le problème est apparemment dû à l'incompatibilité entre Entity Framework 6.1.0 et les échafaudages dans Visual Studio 2013 Update 2 et au dessus de.
Pour mettre à niveau EF, procédez comme suit:
Uninstall-Package EntityFramework -Force
EntityFramework du paquet d'installation
Cette réponse est empruntée à ici
Après la mise à niveau, les échafaudages fonctionnent bien pour moi. Assurez-vous d'installer la nouvelle version dans chaque projet pour lequel Entity Framework est requis.
Je suis sur VS 2013 Update 4 et ai exactement le même problème. Cela fonctionne pour moi lorsque je déplace la chaîne de connexion d'un fichier externe vers web.config. Donc, je suppose que vous pouvez essayer de vous assurer de ne pas utiliser l'attribut configureSource pour connectionString lors de l'échafaudage.
Mon web.config avant et après le changement Avant:
<connectionStrings configureSource="connectionStrings.config/>
Après:
<configuration>
<configSections>
<!-- For more information on Entity Framework configuration, visit http://go.Microsoft.com/fwlink/?LinkID=237468 -->
<section name="entityFramework" type="System.Data.Entity.Internal.ConfigFile.EntityFrameworkSection, EntityFramework, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" />
<section name="log4net" type="log4net.Config.Log4NetConfigurationSectionHandler, log4net" />
</configSections>
<log4net configSource="log4net.config" />
<connectionStrings>
<clear/>
<add name="DefaultConnection" connectionString="Data Source=.;Initial Catalog=YourDb;Integrated Security=False;User ID=sa;Password=YourPassword!#;MultipleActiveResultSets=True" providerName="System.Data.SqlClient" />
</connectionStrings>
Je pense que le problème est dû à une mauvaise configuration dans le fichier web.config.
Dans mon cas, j'avais plusieurs sections <entityFramework>
dans web.config, et le problème a été résolu après avoir modifié les configurations.
Cela peut être utile pour les personnes qui n’ont pas installé de paquet de nuget d’échafaudage dans leur solution.
En fait, mvcscaffolding ou t4scaffolding ne sont pas installés et j'ai le même message d'erreur.
Dans mon cas, le problème/bogue a été causé par la modification de la chaîne de connexion.
Voici ce que j'avais/étapes à reproduire.
Chaîne de connexion modifiée pour se connecter à un vrai serveur, comme ceci:
<add name="DefaultConnection"
connectionString="server=myserv;database=MyCustomerDB;user id=myuser;password=mypass"
providerName="System.Data.SqlClient" />
Ensuite, j'ai activé les migrations via nuget, comme ceci:
Ensuite, j'ai créé un contrôleur en utilisant l'option d'échafaudage:
Ensuite, j'ai décidé de faire plus de changements de code et de recommencer à zéro
J'ai changé la chaîne de connexion comme suit, pour utiliser localdb :
<add name="DefaultConnection"
connectionString="Data Source=(LocalDb)\v11.0;AttachDbFilename=|DataDirectory|\aspnet-Test-20141126094523.mdf;Initial Catalog=aspnet-Test-20141126094523;Integrated Security=True"
providerName="System.Data.SqlClient" />
Puis je poursuivis:
Une erreur s'est produite lors de l'exécution du générateur de code sélectionné: 'Exception a été jeté par la cible d'une invocation.
SOLUTION:
Après quelques recherches, ce que j’ai fait consiste à rétablir la chaîne de connexion du web.config
par la chaîne initiale en "serveur réel" (au lieu de localdb). J'ai essayé à nouveau de générer le contrôleur avec des vues. Ça a marché!
Donc, il me semble qu’un problème/bogue de chaîne de connexion ou un problème localdb ... ne peut pas l'expliquer. Peut-être que Visual Studio n'aime pas ce que j'ai fait, je devais conserver mon ancienne chaîne de connexion ...
Quoi qu'il en soit, alors maintenant que j'ai besoin d'un échafaudage, je remplace simplement la chaîne de connexion par celle qui fonctionne. Ensuite, pour tester mon site Web, je le remplace par celui de localdb.
Je vais expliquer un peu plus en anglais pour que tout le monde puisse comprendre. J'espère que cela aidera quiconque Cela se produit car Visual Studio ne parvient pas à se connecter au modèle de base de données.
Cela se produit lorsque vous modifiez le nom et/ou le chemin de la classe qui étend DbContext sans le modifier dans le fichier Web.config (à la partie la plus à l'extérieur de votre projet: la racine).
Exemple:
Imaginez que vous avez échafaudé le code DbContext:
a) Vous avez cliqué avec le bouton droit de la souris sur un dossier de votre projet et ajouté un "Modèle de données d'entité ADO.NET", et vous l'avez nommé "Modèle1".
Vous obtenez le code suivant:
public class Model1 : DbContext
{
// Your context has been configured to use a 'Model1' connection string from your application's
// configuration file (App.config or Web.config). By default, this connection string targets the
// 'Skelleton.Models.Model1' database on your LocalDb instance.
//
// If you wish to target a different database and/or database provider, modify the 'Model1'
// connection string in the application configuration file.
public Model1()
: base("name=Model1")
{
}
// Add a DbSet for each entity type that you want to include in your model. For more information
// on configuring and using a Code First model, see http://go.Microsoft.com/fwlink/?LinkId=390109.
// public virtual DbSet<MyEntity> MyEntities { get; set; }
}
b) Vous avez maintenant décidé que le nom que vous venez d'écrire est tout à fait mauvais. Vous le changez donc en AppContext.
Votre code ressemble maintenant à ceci:
public class AppContext : DbContext
{
// Your context has been configured to use a 'AppContext' connection string from your application's
// configuration file (App.config or Web.config). By default, this connection string targets the
// 'Skelleton.Models.AppContext' database on your LocalDb instance.
//
// If you wish to target a different database and/or database provider, modify the 'AppContext'
// connection string in the application configuration file.
public AppContext()
: base("name=AppContext")
{
}
// Add a DbSet for each entity type that you want to include in your model. For more information
// on configuring and using a Code First model, see http://go.Microsoft.com/fwlink/?LinkId=390109.
// public virtual DbSet<MyEntity> MyEntities { get; set; }
}
Ensuite, vous essayez d'échafauder les opérations CRUD (Créer, Lire, Mettre à jour, Supprimer) avec des vues et cela échoue!
Pourquoi donc?
Eh bien, si nous allons dans le fichier web.config, nous pouvons voir la chaîne suivante:
<add name="Model1" connectionString="data source=(LocalDb)\v11.0;initial catalog=Skelleton.Models.Model1;integrated security=True;MultipleActiveResultSets=True;App=EntityFramework" providerName="System.Data.SqlClient" />
(Cette ligne est généralement en dessous de <add name="DefaultConnection"
)
Et là est le problème. Vous devez changer Model1 pour le nom que vous avez donné!
Dans ce cas, il devrait dire "AppContext" au lieu de "Model1"
Et où il est dit:
initial catalog=Skelleton.Models.Model1;
Vérifier que:
C'est le nom du fichier .cs qui a la classe
L'espace de nom (ou la série de noms (séparés par des points) précédant le nom de votre classe) est le bon. Il est important de noter que vous n’ajoutez pas à la fin l’extension ".cs"; juste le nom de votre fichier.
Ça devrait ressembler à ça:
Parce que j'ai changé le nom de la classe, à la fois en interne et en externe (à l'intérieur de celle-ci et de son nom de fichier), et que not n'a pas changé son emplacement, je l'ai renommé en AppContext
Après cela a été fait. Vous pouvez échafauder normalement;)
J'espère que cela t'aides!
dans mon cas, j’ai résolu le problème de la chaîne de connexion dans le fichier web.config.
Avant le problème que j'ai
<connectionStrings configSource="Configs\ConnectionString.config"/>
et je ne sais pas pourquoi, mais je ne peux pas me connecter à la base de données et échouer.
après le changement
<connectionStrings>
<add name="UIBuilderContext" connectionString="metadata=res:/ ..... " />
</connectionStrings>
et il fonctionne
Pour moi, je devais m'assurer que les tags <configSettings>
, <appSettings>
et <connectionStrings>
étaientPASen utilisant un attribut configSource
.
J'étais toujours capable d'utiliser les attributs configSource
ailleurs, tels que la balise rewriter
.
J'ai effectué les opérations suivantes pour résoudre ce problème:
Cela a produit le contrôleur et des vues pertinentes pour moi.
J'ai ajouté une vue partielle personnalisée appelée QuickView dans ce dossier, mais cette procédure d'échafaudage n'en tenait pas compte et ne générait que les vues qu'elle effectuait par défaut. Je ne sais pas si vous devez ajouter ces vues personnalisées dans un fichier pour que Scaffolder les génère également.
Je lance VS 2015RC le dernier avant la coupe finale. Ne négligez aucune des solutions ici. Ma solution se trouvait dans le gestionnaire de packages de pépites et a mis à jour mon package Microsoft.Aspnet.Mvc 5.2.3, ce qui corrige mon problème… .. J'espère que cela aidera toute personne utilisant VS 2015.
J'ai eu ce même problème dans la mise à jour 4. J'ai trouvé que le problème venait du <configSections></configSections>
n'ayant pas de nom de section défini. Le correctif que j'ai mis entre les balises est le suivant et toutes les erreurs ont été corrigées:
<section name="entityFramework"
type="System.Data.Entity.Internal.ConfigFile.EntityFrameworkSection,
EntityFramework, Version=6.0.0.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089" requirePermission="false" />
Construisez le projet et tout devrait fonctionner. À votre santé!
j'ai utilisé Initializer et quand retirer/commenter Initializer du constructeur DbContext, l'échafaudage fonctionne bien
public myDbContext () : base("name=DefaultConnection")
{
//Database.SetInitializer(new DropCreateDatabaseIfModelChanges<DastanakDbContext>());
//Database.Initialize(true);
}
Pour moi, ce qui a fonctionné a été de s’assurer que le noeud <configSections>
du fichier web.config était le premier noeud immédiatement après le noeud <configuration>
.
Initialement, lorsque j'ai ajouté ma connectionStrings
, je l'avais effectivement placée avant la configSections
, ce qui a entraîné la rupture de l'outil Scaffold.
On dirait que lorsque l'échafaudage est exécuté et tente de récupérer les informations de connexion, il s'attend à ce que la section config du nœud entityFramework soit déjà présente afin de savoir quel fournisseur de base de données utiliser, mais je ne savais pas quand d'utiliser LocalDB (c'est ce que ma chaîne de connexion utilisait).