Pourquoi l'option «Définir comme démarrage» est-elle stockée dans le fichier suo et non dans le fichier sln?

175

Il semble que ce paramètre doit être stocké dans le fichier de solution afin qu'il soit partagé entre tous les utilisateurs et fait partie du contrôle du code source. Puisque nous ne archivons pas le fichier suo, chaque utilisateur doit le définir séparément, ce qui semble étrange.

c# visual-studio

— Léora
source

46

Pourquoi devrait-il s'agir d'une préférence non spécifique à l'utilisateur?

Si j'ai une solution avec 10 fichiers et qu'un développeur teste / utilise principalement l'un de ces outils, pourquoi cela devrait-il affecter ce que je démarre?

Je pense que MS a fait le bon choix sur celui-ci. Le projet que je veux démarrer est loin d'être forcément le projet que les autres développeurs veulent démarrer.

— Jon Skeet
source

133

Souvent, vous aurez un projet qui est très probablement le projet de démarrage souhaité par la plupart des gens pour le débogage (par exemple, un site Web), et vous ne voulez pas d'une bibliothèque de classes comme projet de démarrage. Je ne vois pas pourquoi MS n'a pas pu fournir un mécanisme approprié (pas ce qui semble être un hack, c'est-à-dire mettre celui par défaut en haut du fichier .sln) pour définir un projet de démarrage global par défaut, puis autoriser un. suo pour le remplacer si vous le souhaitez.

— Jez

27

Il y a, en quelque sorte ... Déplacez le projet que vous voulez définir comme projet de démarrage par défaut pour être le premier projet dans le fichier sln. Supprimez votre fichier suo, rouvrez la solution et woila, ce premier projet devrait être le démarrage. Il peut y avoir d'autres facteurs qui contribuent à cela, mais je l'ai trouvé quand j'ai remarqué qu'un projet en particulier continuait à être par défaut lorsque j'ai extrait un projet propre à partir du contrôle de code source.

— misteraidan

2

C'est un problème lors de l'utilisation d'un serveur de build car il faudrait vérifier le suo dans le contrôle de version pour définir le bon projet de démarrage et vérifier le suo dans le contrôle de version est une mauvaise idée.

— markshancock

2

@markshancock: Pourquoi un serveur de build se soucierait-il du projet de démarrage? Je n'ai jamais vu cela comme un problème.

— Jon Skeet

18

Je suis désolé, Jon, mais je vais vous donner un -1 ici. Je suis convaincu que les développeurs devraient avoir la possibilité de télécharger du code, puis d'appuyer sur F5, en m'attendant à ce que la configuration de développement la plus courante soit construite et démarrée. Bien sûr, vous devriez avoir la possibilité d'adapter vos startups à des circonstances personnelles, mais nous devrions être en mesure de définir une valeur par défaut pour la plupart des utilisateurs, comme indiqué ci-dessus. La réponse d'Oliver semble aller dans ce sens, même s'il semble que plusieurs projets de démarrage resteront impossibles à vérifier dans le contrôle de source, ce qui est dommage.

— Stephen Holt

376

Il est absolument nécessaire que chacun puisse définir lui-même son projet de démarrage, comme Jon l'a déjà dit . Mais avoir un défaut dédié serait génial, et comme je peux le dire, c'est possible!

Si vous n'avez pas de fichier .suo dans votre répertoire de solution, Visual Studio sélectionne le premier projet de votre fichier .sln comme projet de démarrage par défaut.

Fermez votre Visual Studio et ouvrez le fichier .sln dans votre éditeur de texte préféré. A partir de la ligne 4, vous voyez tous vos projets encapsulées dans Project- EndProjectlignes.
Coupez et collez le projet de démarrage par défaut souhaité en haut.
Supprimez votre fichier .suo.
Ouvrez votre solution dans Visual Studio. Ta daa!

Y a-t-il un prix spécial si vous savez quelque chose que Jon ne sait pas? ;-)

— Oliver
source

1

Finalement! Cela me dérange depuis longtemps mais plus maintenant! Tkanks :)

— mdonatas

4

Cela semble fonctionner uniquement si ce n'est dans un dossier de solution: je veux dire que cette astuce fonctionne pour les projets racine, d'après mon expérience avec certaines solutions que j'ai.

— jdehaan

25

HOU LA LA! Vous avez attrapé Jon! :))

— Andrei Rînea

3

Et s'il y a deux projets par défaut - comment puis-je les démarrer tous les deux par défaut?

— Amy B

6

@Oliver: Cliquez avec le bouton droit sur Solution -> Définir les projets de démarrage ... -> Plusieurs projets de démarrage. Un clic démarre plusieurs.

— Anton

46

Dans la plupart des cas, il est logique d'avoir une valeur par défaut à ce sujet.

Il serait bien préférable d'accueillir un projet de démarrage par défaut et de le stocker dans le fichier .sln, mais qui peut être remplacé par un développeur dans son fichier .suo. Si le paramètre de démarrage n'est pas trouvé dans le fichier .suo, le projet de démarrage par défaut dans le .sln sera utilisé.

En fait, cela a été suggéré sur UserVoice de Visual Studio .

— Wim Hollebrandse
source

Le UserVoice lié est "fermé pour vote" mais aucun commentaire sur la raison.

— yzorg

C'est certainement la meilleure position par rapport à la réponse acceptée. Je n'ai pas une seule fois travaillé au sein d'une équipe qui considérait que c'était un avantage de définir cela par utilisateur. Cela conduit juste à une configuration supplémentaire sur de nouveaux clones, etc.

— Trevor Reid

3

J'ai écrit un petit utilitaire de ligne de commande pour Windows appelé slnStartupProjectpour définir automatiquement le projet de démarrage:

slnStartupProject slnFilename projectName

Je l'utilise personnellement pour définir le projet de démarrage après avoir généré la solution avec cmake qui définit toujours un ALL_BUILDprojet factice comme premier projet de la solution.

La source est sur GitHub. Les fourchettes et les commentaires sont les bienvenus.

— michaK
source

Merci pour cela! J'avais exactement ce problème avec cmake et votre utilitaire fonctionne très bien!

— sippa

1

Vous êtes les bienvenus! Heureux, cela aide car cela me dérange depuis des années avant que je décide de résoudre ce problème pour de bon. Je ne comprends pas vraiment pourquoi les gens se battent philosophiquement à ce sujet alors que c'est clairement utile dans la plupart des cas.

— michaK

Vous ... attendez ... quoi? - vous générez votre fichier .sln manuellement? ... quelle sorcellerie est-ce?

— BrainSlugs83

3

Si vous utilisez GIT, vous pouvez valider le fichier SUO par défaut, puis le marquer comme inchangé à l'aide de

git update-index --assume-unchanged YourSolution.suo

Cela fonctionne également si vous souhaitez avoir plusieurs projets dans votre groupe de démarrage par défaut. Le seul inconvénient que je connaisse est que cette commande doit être exécutée par tous ceux qui ne veulent pas valider le fichier SUO.

— Sébetovsky
source