web-dev-qa-db-fra.com

Erreur MSBuild "CSC: erreur CS2001: le fichier source 'x' est introuvable" avec les fichiers liés après la mise à niveau vers Visual Studio 2012

Après la mise à niveau automatique du fichier de projet pour qu'une application Web .Net 4.0 fonctionne avec Visual Studio 2012, tout a bien fonctionné au début, mais lors de la compilation, de nombreuses erreurs telles que celle-ci ont été commises:

Description: le fichier source '..\..\..\..\..\..\Chemin du fichier' est introuvable

Fichier: CSC

Et lorsque j'essayais de créer à l'aide de MSBuild (en passant juste le chemin complet du projet, sans aucun paramètre supplémentaire) dans "l'invite de commande du développeur pour VS2012", j'avais les mêmes erreurs:

"CSC: erreur CS2001: le fichier source 'x' n'a pas été trouvé"

Toutes les erreurs font référence à Linked Files (aspx, cs, etc.) situés dans d’autres projets d’applications Web situés à un emplacement différent de notre code Branch (c’est pourquoi tous les '.... \' au début des chemins )

Pour moi, cela ressemble à un problème avec le fichier Length, j'avais le même problème il y a quelque temps lors de la construction des projets sur notre serveur CI avec MSBuild, j'ai pu le gérer en manipulant les fichiers de projet avant de les construire en utilisant un script personnalisé sans qu'il soit nécessaire de déplacer la branche ou de réduire la profondeur des projets, je n'avais rien à déplacer, ce qui était important à l'époque, c'est que les développeurs utilisant Visual Studio 2010 pouvaient tout compiler sans problèmes. J'ai appris par cela que compiler/compiler avec MSBuild était différent de celui de DevEnv/VS, et par exemple, MSBuild ne supportait pas la construction de projets d'installation et DevEnv.

Comme cela se produit maintenant avec VS 2012/DevEnv 2012, en plus que VS 2012 ne prend plus en charge les projets de configuration (comme msbuild), plus VS/DevEnv ont le même problème avec la longueur du fichier, il semble que VS 2012 utilise finalement msbuild sous le capot ou sont plus étroitement intégrés, cependant je n'ai trouvé aucun article pour le confirmer. 

Changer la structure de la branche/modifier la profondeur des projets n’est pas une option pour le moment pour plusieurs raisons (base de code importante, nombre élevé de projets, risque, calendrier, efforts, etc.). 

Quelqu'un a-t-il une solution alternative ou un correctif pour ce problème dans Visual Studio 2012?

Cordialement,

P.D .: BTW J'ai déjà vérifié ce post Erreur MSBuild avec les fichiers liés mais comme je l'ai dit avant de changer les chemins, ce n'est pas une option pour le moment.

32
Jhonatan P

Je sais que j'ai posé cette question il y a quelque temps, mais pour ce qui en vaut la peine, l'approche que nous avons finalement adoptée était la suivante:

  • Localisation des fichiers signalés comme étant trop longs. 
  • Réduisez la longueur du chemin d'accès complet de ces fichiers en réduisant la longueur du nom et/ou La longueur du dossier conteneur ou en réduisant le niveau d'imbrication des dossiers Par conséquent, réduire la longueur totale du chemin.
  • Mettez à jour les liens des fichiers modifiés (nouvelle liaison) sur les projets dépendants.

Cela a résolu le problème lié à Visual Studio 2012 sur les postes de travail de développeurs et sur nos serveurs CI/Deploy utilisant MSbuild.

Selon mon scénario, cette approche était moins risquée et impliquait moins d’efforts que le déplacement de projets/solutions complets pour réduire leur niveau d’imbrication de dossiers ou de noms de dossiers et mettre à jour toutes les références des projets/solutions dépendants.

1
Jhonatan P

Essayez d’obtenir les journaux de construction, 

http://msdn.Microsoft.com/en-us/library/vstudio/ms171470.aspx

il semble que la tâche csc n'a pas pu trouver le fichier source. Une des raisons est que vous importez le mauvais fichier . Vous devez donc éditer le fichier de projet via l'éditeur de texte normal.

4
N.K

J'ai trouvé une solution à ce problème, lorsque vous avez lié le fichier, votre chemin relatif est reconnu par msbuild et vous revenez en arrière il devient votre chemin dans un long chemin, mais vous pouvez le modifier dans la définition du projet en faisant un clic droit/décharger le projet/et changez le chemin d'accès de ../../../ à $(SolutionDir)/../.. jusqu'à trouver le fichier à lier, remarque: étend le caractère de 255 à 300.

2
user5688731

Ok, j'ai frappé ceci et l'ai résolu aujourd'hui. Je l'ai trouvé en suivant un didacticiel msdn ( https://msdn.Microsoft.com/en-us/library/ms379563%28v=vs.80%29.aspx ) et voici la commande qui a été interrompue pour moi:

csc /t:library /out:MyCodeLibrary.dll simpleType.cs

Me donner le message

error CS2001: Source file 't:librabry' could not be found

Ce qui a fonctionné après avoir modifié la commande d'origine comme suit:

csc /target:library /out:MyCodeLibrary.dll simpleType.cs

Je ne suis pas sûr de savoir pourquoi la version courte de l'indicateur/target est à l'origine de cette erreur, mais je n'ai trouvé aucun autre site en ligne mentionnant spécifiquement cette cause, aussi je voulais l'enregistrer ici.

1
Jomtung

Ce problème s'est posé à moi lorsque je suis revenu à une version antérieure d'un référentiel git. Apparemment, je n’ai pas ajouté le fichier de projet au référentiel; lorsqu’il est retourné, le fichier de projet n’a pas également été inversé. Ce que j'ai fait pour éclaircir le texte a été d'exclure le fichier .cs manquant du projet en cliquant sur le fichier manquant dans l'explorateur de projet. C'était facile à trouver puisqu'il était marqué d'un triangle de présignalisation. Reconstruisez ensuite la solution complète.

0
Weej
  1. Vérifiez que vous disposez de la dernière version des fichiers liés des autres projets. Visual Studio ne les obtiendra PAS automatiquement s'ils appartiennent à un autre projet.
  2. Vérifiez que les chemins liés sont bien corrects. Vous pouvez contrôler les fichiers auxquels VS.NET et MSBUILD tentent d'accéder à l'aide de l'outil SysInternals ProcMon (filtrez les noms de processus et filtrez tous les succès).
  3. Si vous pensez que la longueur du chemin est le problème (elle sera également visible dans l'outil ProcMon), vous pouvez essayer de les raccourcir en les liant au chemin absolu (C:\X\Y\Z) au lieu d'un chemin relatif ( ......\Z). L'emplacement des fichiers liés peut alors rester inchangé.
0
Marc Selis

Mes deux sous à ce problème ... Dans mon cas, un fichier a été créé dans un projet (ConfigModel) et un lien vers ce fichier dans un autre projet, mais lorsque j'ai renommé le fichier ConfigModel dans le premier projet, LoginModel pour Par exemple, il n'a pas renommé le lien dans le deuxième projet, ce qui a provoqué cette erreur.

0
Thierry
  1. Vérifiez si les fichiers mentionnés dans l'erreur n'existent pas dans le dossier correspondant.
  2. Si leur non-existence est intentionnelle, éditez les fichiers .csproj et supprimez la référence pour ces fichiers.
  3. Construire à nouveau.
0
Elayamathy