Можно ли хранить конфигурацию сборки в файле, отличном от файла решения?

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

Чтобы ускорить компиляцию, я запретил сборку большинства проектов в моей новой конфигурации сборки. Чтобы ускорить отладку, я задал сборку большинства проектов для выпуска в моей новой конфигурации сборки.

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

Можно ли сохранить мою конфигурацию сборки в отдельном файле? Идеи обходных путей приветствуются.


visual-studio msbuild visual-studio-2013 buildconfiguration project-files
person Hoppe    schedule 11.09.2014    source источник
comment
Я удивлен, что вы можете смешивать отладочные и выпускные сборки для отладки, вы используете только простые статические библиотеки C или около того? Или С#?   -  person stijn    schedule 11.09.2014
comment
В отладку ставлю только те проекты, которые хочу отладить, а остальные в релиз - C#/VB.NET   -  person Hoppe    schedule 11.09.2014

Ответы (1)


arrow_upward
2
arrow_downward

Чтобы ответить на вопрос напрямую: нет, вы не можете хранить свою конфигурацию в отдельном файле. Если, конечно, эти отдельные файлы также не являются файлом решения. Но есть некоторые обходные пути, все они хранятся локально на вашем компьютере (слишком длинный комментарий, поэтому я все равно отправляю ответ):

Я запретил сборку большинства проектов в моей новой конфигурации сборки

  • просто создайте их один раз, а затем выгрузите проекты, чтобы они не собирались снова. Эти настройки хранятся в файле .suo.
  • если вы настаиваете на сохранении отдельной конфигурации сборки: спросите команду, можно ли поместить ее в систему управления версиями, может быть, другие тоже получат от этого пользу?
  • или напишите скрипт для преобразования исходного файла решения в файл с нашей конфигурацией сборки. Это может быть так же просто, как применить патч, который вы должны постоянно обновлять.

Чтобы ускорить отладку, я установил сборку большинства проектов для выпуска

  • написать скрипт для удаления файлов pdb этих проектов
  • для C++: добавьте все пространства имен этих проектов в файл natstepfilter
person stijn    schedule 11.09.2014
comment
Похоже, я буду писать приложение для циклического просмотра файла решения. Спасибо! - person Hoppe; 12.09.2014
comment
Не должно быть полноценным приложением: самое простое — создать патч из ваших модификаций, сохранить его и всякий раз, когда исходный код изменяется, отменить решение и снова применить патч. Например, в Git все это встроено, так что это всего пара строк в командном файле. - person stijn; 12.09.2014
comment
Хорошая точка зрения. Я использую ТФС. Я помещу команды shelve/unshelve в командный файл. Будем надеяться, что по мере изменения решения слияние не станет слишком хлопотным. Если это произойдет, может быть, тогда я напишу приложение - person Hoppe; 13.09.2014
comment
Создайте свой отдельный файл решения и настройте его по своему усмотрению. Легче добавить свежие изменения, которые вам нужны, из main в ваше решение, чем слияние, особенно когда возникают конфликты слияния. - person Alexey Shcherbak; 14.09.2014