Visual Studio 2010 indique que la construction a échoué sans erreur après la modification d'un fichier source
J'ai une solution Visual Studio 2010 avec quelques projets. Je peux construire avec succès avec Build -> Build Solution ou Build -> Build MyCompany.MyProduct.MyProject. Après la construction, appuyez sur CTRL + F5 et exécutez le projet de démarrage avec succès. Cela fonctionne comme prévu.
Après avoir modifié un fichier source, enregistrez-le, puis créez-le à nouveau (avec Build -> Build Solution ou Build -> Build MyCompany.MyProduct.MyProject). Je peux toujours appuyer sur CTRL + F5 et exécuter le projet de démarrage. Cela fonctionne à nouveau comme prévu.
Le problème provient du scénario suivant: Et cela ne démarre pas mon projet de démarrage (bien sûr).
Est-ce que je manque quelque chose?
Fermez Visual Studio, supprimez le fichier .suo de votre solution. C'est un «fichier caché» dans Windows qui contient les préférences de l'utilisateur, mais il peut aussi faire des choses désagréables.
Cela semble un peu tard, mais ce qui a fonctionné pour moi a été de vérifier ma fenêtre de sortie.
J'ai eu une référence à une fonction qui n'existait pas encore. Je ne sais pas pourquoi cela n'a jamais été mentionné dans la liste des erreurs, mais la fenêtre de sortie m'a indiqué exactement où se trouvait le problème.
Essayez de répéter les mêmes étapes en modifiant l'emplacement où vous avez compilé/exécuté. Assurez-vous que votre nouvel emplacement a moins de dossiers à parcourir par rapport à votre ancien emplacement. Un long chemin d'accès au code source m'avait posé un problème similaire et je l'ai surmonté en choisissant un chemin plus court.
J'ai fermé mon studio visuel.
Supprimé chaque dossier bin. (J'ai eu une erreur de permission étrange, alors j'ai supprimé les fichiers et la piste arrière a supprimé les dossiers, y compris bin).
Studio visuel rouvert. Effectué construire ou reconstruire et tout fonctionnait à nouveau.
Vérifiez le chemin physique de votre projet, si est trop long, copiez le projet dans un dossier de répertoire racine avec un nom très court ..__et essayez de construire votre projet.
J'ai eu ce problème et un avertissement, mais je n'ai trouvé aucune erreur. Finalement, j'ai copié la commande de construction à partir de la fenêtre de sortie dans une fenêtre de commande et je l'ai exécutée manuellement. Elle a généré quatre erreurs après l'avertissement. Je ne sais pas pourquoi cela a fonctionné.
La commande requise doit porter la mention "CoreCompile" et ressembler à ceci: C:\Windows\Microsoft.NET\Framework\v4.0.30319\Csc.exe /noconfig /nowarn:1701,1702,2008 /nostdlib+ /errorreport:Prompt /warn:4 /define:TRACE;SILVERLIGHT;WINDOWS_PHONE /errorendlocation /preferreduilang:en-US /highentropyva- /reference:"C:\Dropbox\code
Si vous ne le voyez pas, essayez de modifier vos paramètres de sortie de construction sous Outils-> Options-> Projets et solutions-> Construire et exécuter, définissez "Verbosité de sortie de la construction du projet MSBuild" sur Normal ou supérieur.
Si d’autres personnes rencontrent ce problème (j’avais déjà essayé de supprimer le fichier SUO mais cela ne fonctionnait pas pour moi):
Je l'ai résolu en créant un nouveau projet vierge dans ma solution et en important tous les fichiers source dans le nouveau projet. Probablement le problème était dans le fichier de projet.
J'ai eu le même problème, résolu par l'étape suivante
allez dans Outils-> option-> projets et Solution-> Général, assurez-vous de cocher la case "Toujours afficher la liste des erreurs si la construction se termine avec des erreurs", dans ce cas, Visual Studio affichera la liste des erreurs.
Une autre chose à vérifier est que si l’un de vos fichiers source est ouvert, il ne pourra pas le construire. Je devais redémarrer mon ordinateur.
Je travaillais sur un projet de site Web qui faisait référence à un projet de bibliothèque (dans la même solution) lorsque j'ai rencontré ce problème. La construction a échoué alors que l'éditeur mettait en surbrillance la syntaxe et naviguait vers la source. Très frustrant.
Aucune des autres réponses n'a fonctionné pour moi; Je pensais que ce problème pourrait être lié car j'ai récemment utilisé DBML pour la première fois sur cette machine. Toujours pas tout à fait sûr que ce n'était pas un facteur contributif.
Après le nettoyage de la solution, des fichiers temporaires, du redémarrage de VS, etc., j'ai fini par exclure les 2 fichiers incriminés, ce qui a permis à la solution de se construire correctement.
p.s. J'ai découvert par la suite une erreur dans la page maître codebehind du site Web (faisant référence à une valeur d'énum qui avait été supprimée), qui n'était pas affichée en tant qu'erreur. J'ai déjà eu des erreurs dans le code maître de la page maître derrière des problèmes (apparemment) non liés auparavant; J'essaie de me rappeler d'y vérifier quand une solution simple ne se présente pas.
Parfois, si le chemin du répertoire est supérieur à 248 caractères, la solution échouera . Assurez-vous que le chemin complet est inférieur à celui-ci.
Regards Venkateshwarlu, Développeur MSBI, Hyderabad.
Mon problème venait de la conversion d'un projet fonctionnel vs2008 en vs2010. Tous les autres projets de la solution se sont bien déroulés, mais celui-ci construirait la partie MIDL, puis s'arrêterait et échouerait. Les paramètres de construction détaillés ne révèlent rien. J'ai donc finalement créé un tout nouveau projet avec tous les fichiers identiques. Cela a fonctionné. Ensuite, j'ai comparé les paramètres et enfin, après avoir modifié les différentes parties, j'ai découvert que le projet converti avait MIDL-> Général -> "Compatible avec MkTypeLib". C'était apparemment un paramètre valide dans vs2008, mais dans vs2010, il doit apparemment être réglé sur Oui ou Non (ou hériter).
Cela a résolu mon problème.
si votre solution contient trop de projets,
construire des projets individuellement,
Vérifier quel projet échoue
pour ce projet, vérifiez les références de ce projet, si sur une référence si sa marque est jaune, supprimez cette référence et ajoutez-la à nouveau, puis générez et vérifiez,
ça va marcher
ou
vérifier dans la fenêtre de sortie, chaque ligne, dans une ligne qu'il montre peut-être, la dépendance est leur, mais ne l'a pas trouvé, c'est le problème qui cause
cela peut être dû à une corruption de fichier
Dans mon cas, je n'ai pas vu de bogue Code Contracts dans la fenêtre de sortie:
CodeContracts: xxx: Unhandled Exception: System.IO.FileNotFoundException:
Could not load file or Assembly 'System.Data.SqlServerCe, Version=3.5.1.0,
Culture=neutral, PublicKeyToken=89845dcd8080cc91' or one of its dependencies.
The system cannot find the file specified.
Je l'ai résolu en désactivant Cache Results dans les fenêtres Code Contracts de ce projet, comme suggéré dans cette réponse .
J'ai eu ce problème aujourd'hui aussi ... après avoir modifié la verbosité de build en diagnostic comme l'a suggéré @Jac, j'ai découvert que le problème se trouvait dans l'un de mes fichiers resx. Apparemment, une image a été corrigée ou était trop grande, je l'ai supprimée et cela a fonctionné!
Ce problème concerne-t-il les workflows Sharepoint 2013 dans VS 2013. Pour le résoudre, procédez comme suit:
- Déchargez le projet worklfows (le buggy).
- Supprimer le fichier .csproj.user
Ouvrez le fichier .csproj dans le bloc-notes et supprimez les lignes suivantes:
<PropertyGroup> <VisualStudioVersion Condition="'$(VisualStudioVersion)' == '' or '$(VisualStudioVersion)' < '11.0'">11.0</VisualStudioVersion> <VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>
Une fois le projet RELOADING entré en solution, le VS a ajouté exactement les mêmes lignes AGAIN, mais aucun problème LoaderException maintenant.
J'ai fait face à ce problème il y a deux jours. J'ai vérifié sur la sortie Windows et j'ai constaté qu'il manquait une référence à VBIDE: impossible de trouver l'assembly d'emballage pour la bibliothèque de types VBIDE. J'ai montré tous les fichiers de l'explorateur de solution, les références étendues et j'ai découvert qu'il y avait une référence à cet assemblage. Je ne sais pas comment cette référence est venue dans mon projet et j'étais sûre de ne pas en avoir besoin. Je viens de l'enlever et tout a été corrigé.