Комментарии 31
Изначальная потребность… работа с Solution-Context в рамках событийной модели студии.
т.е. контекст решения (solution-context) по этому вопросу никак не предусмотрен штатными средствами IDE Visual Studio.
Соответсвенно, все Pre/Build события доступны только в рамках проекта, и если вам требуется что-то обслуживать, предположим единожды для 70 проектов в solution, то появляется задачка…
а также, это косвенно связано с подобными вопросами:
… with VS may be you know — how to find out (from the project or targets file) what is currently selected solution configuration? Not project configuration, but solution configuration! When solution and projects have the same Debug/Release configurations everything is trivial, but in our case solution may have custom configurations which simply don't have corresponding matching configurations in any project.
и другие.
Часть решений можно также рассматривать здесь, кстати — stackoverflow.com/q/2295454
Важное замечание — в этом материале рассмотрена не одна проблема, и выше не предлагается конечное решение, просто все описано как продолжение одной истории :) Если нужно конечно решение, см. плагин в ссылках.
Так, на примере развитие базовой модели для этого плагина, требовалась унификация обработки между различными компонентами для изолированных сред (таких как CI и т.п.), поэтому появились задачи на MSBuild Tools и консольный devenv.com, а сним работать через VSPackage просто так нельзя, но есть варианты… и т.п.
Поэтому, для тех у кого схожие потребности(приоритетная событийная модель, взаимодействие с msbuild.exe, взаимодействие с devenv.exe/.com и все что выше), могут быстро решить свои проблемы уже для своих плагинов и прочих решений, в том объеме, в котором это требуется.
Обратите также внимание, что статья не для пользователей Visual Studio, а для разработчиков, как и указано в заголовке. Если же требуется конечное обобщенное общее решение, см. плагин в галереи
… а путь решения.
Вы про что?
VS — тоже по сути путь решения… или что имеется ввиду о_О
Мне вот почему-то оно ни разу не понадобилось.
2 примера в комментарии выше… под обслуживанием имелось ввиду то, что необходимо выполнить для всех проектов сразу и т.п.
Вы же понимаете пример, когда люди создают empty project в solution и делают ~70 проектов зависимых только от него?
У меня в каждом решении всегда есть обычный проект, от которого зависят остальные. Называется обычно как-нибудь вроде (MyPrefix).Common
и кстати, вот это выше:
… When solution and projects have the same Debug/Release configurations everything is trivial, but in our case solution may have custom configurations which simply don't have corresponding matching configurations in any project....
это чел. объясняет мне в личной переписке реальный пример их хард кастомного решения, так что чудеса и не такие бывают :)
т.е. нет, тут еще ничего страшного, там детали куда более прикольные
к примеру, мое решение было взято за основу, однако у них более жесткие вещи и к примеру им требуется нечто вроде коробочного решения для подконтрольных им разработчиков, которые разбросаны по всему миру… ну как я понял
мне вот лично явно не требовалось то, что сейчас нужно им… так что кому что, мое дело рассказать как этого добиться
____
ах да, касательно доп. примеров, когда и что может понадобиться из этого набора…
собственно, плагин(который уже для обычных юзеров) в пример и забыл привести :)
В общем, некоторый набор опций, который может быть достигнут, кратко показан в виде небольших примеров:
* Обзорно в галереи
* В wiki / Examples
например, можете поискать чего-нибудь там, однако, учитывайте, что например материал — Errors.Stop build не означает, что подобное реализуется исключительно на приоритетном уровне в самых верхах UpdateSolution_Begin — нет, это можно реализовать разными путями, тут особых проблем нет, а вот нумерация версий, может быть как раз одним из частных примеров и т.п.
:) а где я написал «независимых»? если они в одном solution, значит они там не просто так…
Вы же понимаете пример, когда люди создают empty project в solution и делают ~70 проектов зависимых только от него?
Когда в solution есть X проект, от которого зависят Y проекты. Этот проект может не производит никаких binaries, а заниматься лишь некоторым обслуживанием которые будут используются при сборке Y проектов. По сути, такой метод может служить для обработки события начала построения именно в нужном контексте для всех Y проектов и т.п.
вы как вообще читаете?
вы как вообще читаете?
А если надо сделать что-то для решения целиком — то kekekeks привел ниже классную ссылку на куда более простое решение, чем у вас сделано.
чего еще нужно то ?! я ведь эти же решения вам и привел в пример!
Я не считал и не считаю удобным вариант с зависимыми проектами, я об этом ни разу не упомянул.
Вы вообще можете не пользоваться IDE для построения, используйте msbuild! что вам мешает ?! ведь он более гибок! добавьте необходимые таргеты и забудьте все как страшный сон…
И сколько уже можно, Здесь не рассматриваются и не предлагаются конечные решения! — это для разработчиков, а вы описываете и требуете примеры для обычных пользователей VS. Прочтите «Предупреждение» что я добавил в материал.
Если вам нужно обсуждение плагина, а также обсуждение вариантов — Solution-wide pre-build event, и вообще какими еще кто пользуется, то быть может лучше создать другую статью специально под это обсуждение ?!
Невозможность работы «плугина» на билд-сервере без студии.
это одна из… что появилась позднее. Да все правильно, это уже было в рамках того плагина в ссылках.
Однако изначально это solution-context, ну например этот комментарий, а также другие приведенные
Этот плагин был отправлен в паблик и доведен до такого состояния, в котором он находиться сейчас, уже в рамках предоставления какого-то общего повторного решения. Опять-таки для тех кто в нем нуждается.
У каждого свой workflow и не всегда по его воли! есть вообще своеобразные «коробочные решения», те что предоставляют подконтрольным подразделениям…
Но еще раз этот, материал призван в первую очередь — осветить некоторые аспекты решения и взаимодействия для разработчиков, для тех кому это понадобиться, т.е. столкнулся с задачей, например как взаимодействовать с devenv.exe или как работать с приоритетной подпиской, и все что выше.
… необходимо осветить некоторые аспекты решения и взаимодействия ...
Оповещений на почту на хабре нет что ли o_O года 2 наверное не попадал на эту страницу. как чувствовал :)
хм, также вроде была авторизация через google, пришлось восстанавливать пароль, странно.
Tarmik, рад, что материал оказался полезным!
в Apr 2016, я также писал еще одну статью по схожей тематике, но целиком посвященную MSBuild в виде альтернативы на плагинувую систему, но at runtime
Так...
По поводу генераторов sln, vcxproj и т.п.
У меня на гитхабе появилось другое, достаточно популярное решение, которое выделялось отдельным проектом спецом для DllExport.
И как оказалось, последние месяцы, это решение стало набирать также популярность среди разработчиков.
К тому же, можно очень быстро прикрутить любой свой обработчик в виде доп. хандлеров чтения/записи.
Хотя, это несколько иное направление.
По поводу сопутствующих решений в данной статье
Говорю сразу (меня часто дергают с vssbe проектом на дальнейшие развитие):
- Проект не обновлялся года 2, НО находиться в [Активном состоянии] (в моей планерке он точно записан, не первым, но далеко не последним местом).
К тому же, он все еще прекрасно справляется с современным VS2017 и MSBuild 15
В последний раз, когда я тесно общался с MS, они занимались реорганизацией структуры от VS до самого маркета, который они все-таки решили выкатить тогда в сыром виде, окончательно заменив первоначальную галерею.
Поэтому, на тот момент времени, я просто переключился на другие задачи, пока они решали свои насущные проблемы <_< по иронии судьбы, одного в итоге ушатали в google :)
Сейчас же я достаточно плотно занят другими вещами, однако конечное решение, описаное в данной статье, оно все еще используется, по крайней мере, в десятках моих других открытых проектов при сборках, кодогенерации, разнообразных паках и т.п.
Однако, все движется, я это прекрасно понимаю, и его дальнейшие направление/позиционирование пока находиться в некоторой абстракции. Но в том или ином виде он все еще существует в моих задачах. Да и народ, вроде как требует продолжения.
В следующем году, я планирую выделить некоторые его компоненты в отдельные открытые проекты, по крайне мере, планы на "статический SBE-scripts (прим. статический, в плане не регистровый, без стека, с обычной интеграцией в runtime с msbuild и т.п.)".
К слову, генератор и парсер sln как раз был выпущен из этого проекта, под более свободной лицензией MIT.
Ваш энтузиазм,
на совместное решение мне понятен :)
Хмм, но по планам, и срокам с этой темой, пока без конкретики, НО да, если что пишите:
- github.com/3F
Рад рассмотреть то или иное сотрудничество.
Прямые контакты там же, но продуктивнее поднять задачки для дальнейшей дискуссии.
p.s. на GitHub я выполнил окончательный переезд с Bitbucket где-то в 2016. То есть, туда ходить не надо. Там остались только парочку открытых репок, на которые были даны ссылки на других ресурсах, в опубликованном коде и т.п. в общем пускай висит пока.
p.p.s. мне пишется "недостаточно кармы", чтобы поставить Вам плюсик
Событийная модель построения проектов и решений Visual Studio для разработчиков