occasionnellement (généralement après avoir mis à jour mon fichier .sln dans le contrôle de la source), je reçois une erreur de studio Visual Strange dans laquelle je ne peux pas ouvrir certains de mes fichiers. Les fichiers en question apparaissent dans le projet approprié, mais en essayant de les ouvrir de résultats dans une boîte de dialogue d'erreur indiquant "Un fichier de ce nom est déjà ouvert."
Ceci est pratiquement identique à Pourquoi Il dit "projet avec ce nom déjà ouvert dans la solution"? , à l'exception des fichiers, pas de projets. La solution donnée là-bas n'a pas réussi cela.
4 Réponses :
Avez-vous des fichiers liés dans la solution?
Visual Studio a un invariant que seul un seul fichier d'un chemin donné peut être ouvert à la fois. Cet invariant est frappé le plus souvent lorsque vous avez un fichier lié dans votre projet / solution et tenter d'ouvrir à la fois l'original et l'une de ses références liées.
Visual Studio Conserve en interne une liste de fichiers actuellement ouverts, afin d'éviter les problèmes causés par l'ouverture de fichiers plus d'une fois. Tout nombre de choses (accidents, redémarrages, mise à jour des fichiers dans le contrôle de la source en dehors de VS) peut entraîner une corruption de cette liste.
Dans tous les cas, le problème peut être corrigé en supprimant le fichier caché Il s'agit d'un fichier caché, afin de la voir ou de la supprimer, vous devez autoriser à afficher des fichiers cachés dans Explorer ou utiliser solution.suo dans le même répertoire que votre fichier solution.sln . Cela vous fera perdre votre état d'espace de travail actuel (fichiers ouverts, disposition de la fenêtre, etc.), mais il n'aura pas d'autres effets indésirables sur votre solution.
del / ah solution.suo sur la ligne de commande.
Utilisation de VS2008 sur Vista, j'ai supprimé le fichier Solution.Sln.Cache au même effet.
Fonctionne pour VS2010 sur le serveur 2008.
Je ne trouve pas l'idée de supprimer le .suo un bon. Pour moi, fermez simplement vs et ouvrez-le à nouveau résoudre le problème.
Dans certains cas, ce problème est déclenché par des modifications de casage des fichiers faisant partie d'une solution. La table de document en marche est principalement strictement sensible à la casse, tandis que sur le disque, plusieurs boîtiers peuvent indiquer le même fichier. Lorsque de tels fichiers sont ouverts et transformés en subversion, parfois, le boîtier change ... Causer cette erreur.
Supprimez le fichier Caché .suo et modifiez le fichier .csproj pour supprimer les lignes ci-dessous: maintenant, rouvrez la solution pour résoudre le problème.
Cela a travaillé pour moi, avait un projet que j'avais changé de subversion à Git. Suppression de ces lignes dans le fichier VbProj résolue cette question.
Ouvrir le fichier CSPROJ du projet et Supprimer les lignes suivantes:
<SccProjectName>SAK</SccProjectName> <SccLocalPath>SAK</SccLocalPath> <SccAuxPath>SAK</SccAuxPath> <SccProvider>SAK</SccProvider>
VisualSVN n'écrit pas ces lignes dans les fichiers de projet.
Vous êtes correct et c'est ce que j'avais écrit qu'il est très probablement créé par Visual Svn, bien que le cas soit lorsque vous ajoutez une solution / projet dans le contrôle de source, le fichier de solution / projet sera mis à jour pour inclure les informations d'intégration de la source de contrôle. . et pendant ce temps ci-dessus les lignes sont ajoutées. - bien que voir la réponse éditée.
Je suis vraiment désolé, mais je ne comprends pas. Le plug-in VisualSvn n'ajoute pas ces lignes aux fichiers de projet ou de solution. Je me souviens que Ankhsvn les ajoute, cependant. Vous pouvez l'essayer vous-même avec un projet propre. :)
J'ai remarqué parfois un
Devenv.exe après les sorties VS, tuer cela résolue ce problème dans mon cas particulier (YMMV).