Здравствуйте, Karpov, Вы писали:
K>Можно ли как-то объяснить студии, чтобы мои плагины вместе с их зависимостями при сборке автоматически раскладывались в каталог plugins\<plugin name> в каталоге со сборкой?
А почему просто не указать куда класть собранные плагины?! В смысле в настройках проекта, Build => Output Path?
C#, VS2019, пишу программу, которая использует плагины.
Все в одном решении, плагины в виде библиотек классов, в зависимостях у программы прописаны плагины, студия при сборке складывает все в один каталог, все работает. Но. Так как плагины используют сторонние компоненты в каталоге с программой получается адовая каша из кучи файлов и определить что к чему относится невозможно. Отсюда вопрос:
Можно ли как-то объяснить студии, чтобы мои плагины вместе с их зависимостями при сборке автоматически раскладывались в каталог plugins\<plugin name> в каталоге со сборкой?
Здравствуйте, Karpov, Вы писали:
K>Можно ли как-то объяснить студии, чтобы мои плагины вместе с их зависимостями при сборке автоматически раскладывались в каталог plugins\<plugin name> в каталоге со сборкой?
В зависимостях к проекту, для либ поставить copy:no.
В либах в свойствах проекта добавить build-postscript, который будет их копировать `plugins\<plugin name>`.
В конфиге проекта(runtimeconfig.json/*.deps.json) прописать ссылки на зависимые либы, ну или добавить код при запуске проекта Assembly.Load('plugins\...').
Підтримати Україну у боротьбі з країною-терористом.
Здравствуйте, #John, Вы писали:
J>Здравствуйте, Karpov, Вы писали:
K>>Можно ли как-то объяснить студии, чтобы мои плагины вместе с их зависимостями при сборке автоматически раскладывались в каталог plugins\<plugin name> в каталоге со сборкой?
J>В зависимостях к проекту, для либ поставить copy:no. J>В либах в свойствах проекта добавить build-postscript, который будет их копировать `plugins\<plugin name>`. J>В конфиге проекта(runtimeconfig.json/*.deps.json) прописать ссылки на зависимые либы, ну или добавить код при запуске проекта Assembly.Load('plugins\...').
А в build-postscript я могу как-то адресоваться к каталогу сборки проекта, который зависит от либы, или придется прибивать гвоздями к абсолютным путям? Хотелось бы, чтобы решение было переносимым...
Здравствуйте, Karpov, Вы писали:
K>А в build-postscript я могу как-то адресоваться к каталогу сборки проекта, который зависит от либы, или придется прибивать гвоздями к абсолютным путям? Хотелось бы, чтобы решение было переносимым...
--
Можно и без студии, просто сделать отдельно батник/(sh скрипт для wsl: bash -c "cd ..; dotnet build ; cp .. .."), который будет билдить все плагины, копировать в нужную директорию.
Впринципе, второй вариант мне больше нравится, т.к. про build-post скрипт другой человек может сразу и не догадаться.
А батник, сразу на виду и его подправить меньше времени займет, чем открывать проект в студии, но тут тоже есть свои минусы.
Підтримати Україну у боротьбі з країною-терористом.
K>>Можно ли как-то объяснить студии, чтобы мои плагины вместе с их зависимостями при сборке автоматически раскладывались в каталог plugins\<plugin name> в каталоге со сборкой?
J>В зависимостях к проекту, для либ поставить copy:no. J>В либах в свойствах проекта добавить build-postscript, который будет их копировать `plugins\<plugin name>`.
у вас дебаг, скорее всего, не будет нормально работать так как скомпилированные pdb файлы будут в другом месте лежать
K>Можно ли как-то объяснить студии, чтобы мои плагины вместе с их зависимостями при сборке автоматически раскладывались в каталог plugins\<plugin name> в каталоге со сборкой?
как написали ранее, в настройках проектов плагинов надо задать правильный output параметр.
Здравствуйте, bnk, Вы писали:
bnk>Здравствуйте, Karpov, Вы писали:
K>>Можно ли как-то объяснить студии, чтобы мои плагины вместе с их зависимостями при сборке автоматически раскладывались в каталог plugins\<plugin name> в каталоге со сборкой?
bnk>А почему просто не указать куда класть собранные плагины?! В смысле в настройках проекта, Build => Output Path?
Как ни странно, именно так я и сделал и оно вполне работает — в каталоге с решением сделал каталог bin, куда банально перенаправил вывод всех сборок. Оказывается, студия прекрасно понимает относительные пути вида ../bin/Debug/... и даже сама их подставляет вместо полных путей.
Вобчем, я не настоящий программист и узнал много нового. Спасибо.
Здравствуйте, Karpov, Вы писали:
K>Вобчем, я не настоящий программист и узнал много нового. Спасибо.
Скромно, не каждый задумается об автоматизации сборки.
Большая проблема msbuild что триггер публикации срабатывает несколько раз.
Я обхожу это через создание файла флажка и чекаю его наличие в скрипте (fsx).
Довольно удобный язык для скриптов, правда рантайм жутко тормозной. ну для скриптования потянет.
Есть еще fake(поверх F#) но его я еще изучал.
AA>Большая проблема msbuild что триггер публикации срабатывает несколько раз. AA>Я обхожу это через создание файла флажка и чекаю его наличие в скрипте (fsx).
Что вы имеете ввиду?
set slnConfiguration=Release
rem Build the solution
dotnet build %slnFolderName%\%slnFolderName%.sln -c %slnConfiguration%
rem ...
rem Publish main project (and all dependencies)
dotnet publish -r win10-x64 -c:%slnConfiguration% -p:PublishSingleFile=true -o:"..\output\publish" %projectName%\%projectName%.csproj
Здравствуйте, Вертер, Вы писали:
AA>>Большая проблема msbuild что триггер публикации срабатывает несколько раз. AA>>Я обхожу это через создание файла флажка и чекаю его наличие в скрипте (fsx). В>Что вы имеете ввиду?
Для увеличения номера сборки использую скрипт и триггер паблиш, так вот он может в зависимости от
сложности решения несколько раз выполняться хз почему, поэтому при первом выполнении создается флажок.
суть задачи получить версию, номер сборки увеличивается при релизе(хранится в файлике), а ревизия берется из свн.