Почему опция «Установить как автозагрузку» хранится в файле suo, а не в файле sln?

175

Кажется, что этот параметр должен быть сохранен в файле решения, чтобы он был общим для всех пользователей и частью контроля исходного кода. Поскольку мы не регистрируем файл suo, каждый пользователь должен установить это отдельно, что кажется странным.

Лиора
источник

Ответы:

46

Почему это должно быть не для пользователя?

Если у меня есть решение с 10 файлами, и один разработчик в основном тестирует / использует один из этих инструментов, почему это должно влиять на то, что я запускаю?

Я думаю, что MS сделал правильный выбор на этом. Проект, который я хочу начать, далеко не обязательно тот, который хотят запустить другие разработчики.

Джон Скит
источник
133
Часто у вас будет проект, который, скорее всего, будет желаемым проектом запуска большинства людей для отладки (например, веб-сайт), и вы не хотите, чтобы библиотека классов была запущенным проектом. Я не понимаю, почему MS не может обеспечить надлежащий механизм (а не то, что кажется хаком, то есть поместить стандартный по умолчанию вверху в файле .sln) для установки глобального запускаемого по умолчанию проекта запуска, а затем разрешить. так, чтобы переопределить его, если это необходимо.
Jez
27
В некотором смысле ... Переместите проект, который вы хотите установить в качестве начального проекта по умолчанию, в качестве первого проекта в файле sln. Удалите файл suo, снова откройте решение и вуаля, этот первый проект должен быть при запуске. Могут быть и другие факторы, которые способствуют этому, но я обнаружил это, когда заметил, что один конкретный проект продолжал работать по умолчанию, когда я извлек чистый проект из системы контроля версий.
misteraidan
2
Это проблема при использовании сервера сборки, потому что для установки правильного Startup-проекта требуется проверка suo в управлении версиями, а проверка suo в управлении версиями - плохая идея.
маршанкок
2
@markshancock: Почему сервер сборки заботится о запуске проекта? Я никогда не видел это как проблему.
Джон Скит
18
Прости, Джон, но я собираюсь дать тебе -1 здесь. Я верю, что разработчики должны иметь возможность загружать код, а затем нажимать клавишу F5, ожидая, что будет построена и запущена самая обычная настройка разработки. Конечно, вы должны иметь возможность адаптировать свои стартапы к личным обстоятельствам, но мы должны быть в состоянии установить значение по умолчанию для большинства пользователей, как указано выше. Кажется, что ответ Оливера каким-то образом это делает, хотя кажется, что несколько начальных проектов по-прежнему невозможно проверить в системе контроля версий, что является позором.
Стивен Холт
376

Абсолютно необходимо, чтобы каждый мог определить свой StartUp Project самостоятельно, как уже сказал Джон . Но иметь выделенное значение по умолчанию было бы здорово, и, как я могу судить, это возможно!

Если в каталоге решений нет файла .suo, Visual Studio выберет первый проект в вашем файле .sln в качестве запускаемого по умолчанию проекта.

  1. Закройте Visual Studio и откройте файл .sln в вашем любимом текстовом редакторе. Начиная в строке 4, вы видите все ваши проекты , инкапсулированные в Project- EndProjectлинии.

  2. Вырежьте и вставьте нужный проект запуска по умолчанию в верхнюю позицию.

  3. Удалите файл .suo.

  4. Откройте свое решение в Visual Studio. Та даа!

Есть ли специальная награда, если вы знаете что-то, чего не знает Джон? ;-)

Оливер
источник
1
Finaly! Это беспокоило меня долгое время, но не больше! Tkanks :)
mdonatas
4
Кажется, что это работает, только если не в папке решений: я имею в виду, что этот трюк работает для корневых проектов, исходя из моего опыта с некоторыми решениями, которые у меня есть.
jdehaan
25
ВОТ ЭТО ДА! Ты скинул Джон! :))
Андрей Ринея
3
Что, если есть два проекта по умолчанию - как я могу запустить их оба по умолчанию?
Эми Б
6
@Oliver: щелкните правой кнопкой мыши Solution -> Set Startup Projects ... -> Несколько запускаемых проектов. Один клик запускает несколько.
Антон
46

В большинстве случаев имеет смысл установить значение по умолчанию.

Было бы намного лучше разместить проект запуска по умолчанию и сохранить его в файле .sln, но он может быть переопределен разработчиком в их файле .suo. Если параметр запуска не найден в файле .suo, будет использоваться проект запуска по умолчанию в .sln.

На самом деле, это было предложено в UserVoice Visual Studio .

Вим Холлебрандсе
источник
Связанный UserVoice «закрыт для голосования», но нет комментариев относительно того, почему.
yzorg
Это определенно лучшая позиция по сравнению с принятым ответом. Я ни разу не работал в команде, которая считала преимуществом устанавливать это для каждого пользователя. Это просто приводит к дополнительной настройке свежих клонов и т. Д.
Тревор Рейд
3

Я написал небольшую утилиту командной строки для Windows, slnStartupProjectкоторая вызывается для автоматической установки Startup Project:

slnStartupProject slnFilename projectName

Я лично использую его для настройки запуска проекта после генерации решения с помощью cmake, который всегда устанавливает фиктивный ALL_BUILDпроект в качестве первого проекта в решении.

Источник находится на GitHub. Форкс и отзывы приветствуются.

michaK
источник
Спасибо за это! У меня была именно эта проблема с cmake, и ваша утилита прекрасно работает!
Sippa
1
Пожалуйста! Счастлив, что это помогает, так как это беспокоило меня много лет, прежде чем я решил решить эту проблему навсегда. Не очень понимаю, почему люди ведут философскую борьбу по этому поводу, хотя в большинстве случаев это явно полезно.
michaK 29.12.14
Вы .. подождите ... что? вы создаете файл .sln вручную? ... что это за колдовство?
BrainSlugs83
3

Если вы используете GIT, вы можете зафиксировать файл SUO по умолчанию, а затем пометить его как неизмененный, используя

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

Это также работает, если вы хотите иметь более одного проекта в стартовой группе по умолчанию. Единственный недостаток, о котором я знаю, это то, что эту команду должны выполнять все, кто не хочет фиксировать файл SUO.

sebetovsky
источник