2010-09-20 8 views
0

J'ai récemment reconstruit ma machine de développement. Sur cette nouvelle machine, VS 2010 ne peut plus ouvrir les fichiers sln directement à partir de SS 2005. Ce sont des solutions 2010 valides (créées initialement avec VS 2010) qui ont fonctionné correctement jusqu'à ce que je reconstruise ma machine.Fichier de solution invalide Visual Studio 2010 et SourceSafe 2005

Le message que j'obtiens est "Le fichier sélectionné n'est pas un fichier de solution valide".

J'ai reconstruit plusieurs fois et utilisé de nombreuses installations de VS et n'ai jamais eu de problème à ouvrir les sln de SS en utilisant VS 05, 08 ou 10. Je n'ai jamais vu ça auparavant.

J'ai réinstallé SS 2005 ainsi que la dernière mise à jour SS mais rien ne fonctionne.

VS 2010 peut très bien ouvrir des solutions à partir du système de fichiers, il doit donc s'agir d'un SS.

Des idées?

Très bien, merci. J'ai créé une application de console et l'ai vérifiée dans SS. Pas de problème. Lorsque je le supprime de mon système de fichiers local et que j'essaie d'obtenir la solution de SS, j'obtiens la même erreur. Je dirais qu'il n'y a rien de mal avec le fichier sln, mais voici le texte du fichier:

fichier Solution Microsoft Visual Studio, Format Version 11.00

Visual Studio 2010

Projet ("{FAE04EC0-301F- 11D3-BF4B-00C04F79EFBC} ") = "ConsoleApplication1", "ConsoleApplication1 \ ConsoleApplication1.csproj", "{748E05CA-D880-4D89-9479-4AB800D79C82}" EndProject mondial GlobalSection (SourceCodeControl) = = SccNumberOfProjects présolution 2 SccLocalPath0 =. SccProjectUniqueName1 = ConsoleApplication1 \ ConsoleApplication1.csproj SccLocalPath1 =. SccProjectFilePathRelativizedFromConnection1 = ConsoleApplication1 \ EndGlobalSection GlobalSection (SolutionConfigurationPlatforms) = présolution Debug | x86 = Debug | x86 Release | x86 = Release | x86 EndGlobalSection GlobalSection (ProjectConfigurationPlatforms) = {postSolution 748E05CA-D880-4D89-9479-4AB800D79C82 } .Debug | x86.ActiveCfg = Débogage | x86 {748E05CA-D880-4D89-9479-4AB800D79C82} .Debug | x86.Build.0 = Débogage | x86 {748E05CA-D880-4D89-9479-4AB800D79C82} .Release | x86.ActiveCfg = Release | x86 {748E05CA-D880-4D89-9479-4AB800D79C82} .Release | x86.Build.0 = Release | x86 EndGlobalSection GlobalSection (solutionProperties) = présolution HideSolutionNode = FAUX EndGlobalSection EndGlobal

Répondre

0

Que faire si vous obtenez la solution à votre disque local de SourceSafe Client et ouvrez à l'aide de Visual Studio?

0

Je me suis heurté exactement à la même situation et il m'a fallu du temps pour comprendre. Dans ma configuration, j'avais un disque SSD avec OS et des programmes dessus, et un gros disque de données. Parce que l'espace SSD était précieux, j'ai déplacé mon dossier de documents sur le lecteur de données. Mon SSD a échoué et j'ai dû reconstruire mon OS et mes programmes sur un nouveau SSD. Tous les projets VS échoueraient alors à charger, comme avec vous.

Il s'avère que le problème n'a en fait rien à voir avec VS en soi.Lorsque j'ai reconstruit le système d'exploitation, même si j'utilisais exactement le même nom d'utilisateur et le même mot de passe, le dossier documents ne me reconnaissait pas uniquement comme propriétaire, il ne me permettait donc pas de lire, d'écrire ou d'effacer des fichiers. Et VS par défaut place vos projets dans votre dossier de documents. C'est un problème d'autorisation de fichier! Pour corriger le problème [sous Windows 7], accédez au dossier ou au fichier affecté et cliquez avec le bouton droit sur> Propriétés. Cliquez sur l'onglet Sécurité et il vous avertira que vous ne possédez pas ce fichier ou dossier. Cliquez sur et sélectionnez vous-même ou tout autre administrateur pour accéder à la page des autorisations (vous n'avez pas encore modifié les autorisations), mais ne cliquez pas encore sur ok. Si vous regardez un dossier, cochez la case en bas de la page de propriétés pour revendiquer la propriété du dossier actuel et tout ce qu'il contient, et cliquez sur OK (si vous ne cochez pas la case, vous devez changer les permissions de chaque fichier dans ce dossier individuellement). Si vous consultez un fichier, cliquez sur OK, puis cliquez à nouveau sur l'onglet Sécurité pour modifier les autorisations et vous ajouter en tant que propriétaire de ce fichier sous la forme: nom_ordinateur \ nom_utilisateur

Une fois que vous possédez tous les fichiers dans le dossier de projet à nouveau, tout devrait fonctionner normalement. Ce même problème affectera de nombreuses applications différentes essayant d'accéder aux documents pré-crash dans le dossier des documents (mais n'a étrangement pas affecté la musique, les images, ni la vidéo). J'ai également eu de gros problèmes avec Adobe CS4, car il utilisait le dossier documents pour communiquer entre les applications (Premiere n'envoyait pas de rendu à AME, et AfterFX plantait au lancement), même si votre projet ne se trouvait pas dans Mes documents. La même solution corrige tout.

Questions connexes