Por que a opção "Definir como inicialização" é armazenada no arquivo suo e não no arquivo sln?

175

Parece que essa configuração deve ser armazenada no arquivo de solução para ser compartilhada entre todos os usuários e parte do controle do código-fonte. Como não fazemos check-in no arquivo suo, cada usuário deve definir isso separadamente, o que parece estranho.

c# visual-studio

— leora
fonte

46

Por que deveria ser uma preferência não específica do usuário?

Se eu tenho uma solução com 10 arquivos e um desenvolvedor está testando / usando principalmente uma dessas ferramentas, por que isso afeta o que eu inicio?

Eu acho que a MS fez a escolha certa nesse caso. O projeto que quero iniciar está longe de ser necessariamente o projeto que outros desenvolvedores desejam iniciar.

— Jon Skeet
fonte

133

Freqüentemente, você terá um projeto que provavelmente será o projeto de inicialização desejado para a maioria das pessoas para depuração (por exemplo, site) e não deseja uma biblioteca de classes como um projeto de inicialização. Não vejo por que a MS não pôde fornecer um mecanismo adequado (não o que parece ser um hack, ou seja, colocar o padrão no topo do arquivo .sln) para definir um projeto de inicialização padrão global e permitir um. suo para substituí-lo, se desejar.

— Jez

27

De certa forma, existe ... Mova o projeto que você deseja definir como o projeto de inicialização padrão para o primeiro projeto no arquivo sln. Exclua seu arquivo suo, abra novamente a solução e woila, esse primeiro projeto deve ser a inicialização. Pode haver outros fatores que contribuem para isso, mas eu o encontrei quando percebi que um projeto em particular continuava em falta quando fiz check-out de um projeto limpo no controle de origem.

— misteraidan

2

Esse é um problema ao usar um servidor de construção, pois exigiria a verificação do suo no controle de versão para definir o projeto de inicialização correto e a verificação do suo no controle de versão é uma má idéia.

— markshancock

2

@markshancock: Por que um servidor de build se importaria com o projeto de inicialização? Eu nunca vi isso como um problema.

— precisa saber é o seguinte

18

Sinto muito, Jon, mas vou lhe dar um -1 aqui. Eu acredito que os desenvolvedores devem ter a capacidade de baixar código e depois pressionar a F5, esperando que a configuração de desenvolvimento mais usual seja criada e iniciada. Obviamente, você deve ter a capacidade de adaptar suas startups para circunstâncias pessoais, mas poderemos definir um padrão para a maioria dos usuários, conforme declarado acima. A resposta de Oliver parece ser uma maneira de fazer isso, embora pareça que vários projetos de inicialização continuem impossíveis de verificar no controle de origem, o que é uma pena.

— Stephen Holt

376

É absolutamente necessário que todos possam definir eles mesmos o seu Projeto de Inicialização, como Jon já disse . Mas ter um padrão dedicado seria ótimo e, como posso dizer, é possível!

Se você não tiver um arquivo .suo no diretório da solução, o Visual Studio selecionará o primeiro projeto no arquivo .sln como o projeto de inicialização padrão.

Feche o Visual Studio e abra o arquivo .sln no seu editor de texto favorito. Começando na linha 4, você vê todos os seus projetos encapsulados em Project- EndProjectlinhas.
Recorte e cole o projeto de inicialização padrão desejado na posição superior.
Exclua seu arquivo .suo.
Abra sua solução no Visual Studio. Ta daa!

Existe um prêmio especial se você souber algo que Jon não sabe? ;-)

— Oliver
fonte

1

Finalmente! Isso me incomoda há muito tempo, mas não mais! Tkanks :)

— mdonatas

4

Parece funcionar apenas se não estiver em uma pasta de soluções: quero dizer que esse truque funciona para projetos raiz, a partir da minha experiência com algumas soluções que tenho.

— jdehaan

25

UAU! Você procurou Jon! :))

— Andrei Rînea

3

E se houver dois projetos padrão - como posso iniciá-los por padrão?

— Amy B

6

@Oliver: Clique com o botão direito em Solução -> Definir Projetos de Inicialização ... -> Vários projetos de inicialização. Um clique inicia vários.

— Anton

46

Na maioria dos casos, faz sentido ter um padrão nisso.

Seria muito melhor acomodar um projeto de inicialização padrão e armazená-lo no arquivo .sln, mas que pode ser substituído por um desenvolvedor em seu arquivo .suo. Se a configuração de inicialização não for encontrada no arquivo .suo, o projeto de inicialização padrão no .sln será usado.

Na verdade, isso foi sugerido no UserVoice do Visual Studio .

— Wim Hollebrandse
fonte

O UserVoice vinculado está "fechado para votação", mas não há comentários sobre o motivo.

— yzorg 13/02/19

Esta é definitivamente a melhor postura em comparação com a resposta aceita. Eu nunca trabalhei em uma equipe que considerasse uma vantagem definir isso por usuário. Ele só leva a configuração adicional sobre clones frescos, etc.

— Trevor Reid

3

Eu escrevi um pequeno utilitário de linha de comando para o Windows chamado slnStartupProjectpara definir o Projeto de Inicialização automaticamente:

slnStartupProject slnFilename projectName

Eu pessoalmente o uso para definir o projeto de inicialização após gerar a solução com o cmake, que sempre define um ALL_BUILDprojeto fictício como o primeiro projeto na solução.

A fonte está no GitHub. Garfos e feedback são bem-vindos.

— michaK
fonte

Obrigado por isso! Eu estava tendo exatamente esse problema com o cmake e seu utilitário funciona muito bem!

— Sippa

1

De nada! Feliz por ajudar, pois me incomoda há anos antes de eu resolver isso de uma vez por todas. Realmente não entendo por que as pessoas têm brigas filosóficas sobre isso, enquanto isso é claramente útil na maioria dos casos.

— michaK

Você .. espera ... o que? - você gera seu arquivo .sln manualmente? ... que feitiçaria é essa?

— BrainSlugs83

3

Se você estiver usando GIT, poderá confirmar o arquivo SUO padrão e marcá-lo como inalterado usando

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

Também funciona se você deseja ter mais de um projeto no seu grupo inicial padrão. A única desvantagem que conheço é que esse comando deve ser executado por todos que não desejam confirmar o arquivo SUO.

— sebetovsky
fonte