Есть проект А, Б. В Б используется А.
Нужно чтоб в результате паблишинга проекта Б, в результат (в bin директорию) подтянулся файл с xml-документацией от проекта А.
Ранее (до апргрейда на студию VS2019) это работало само, после апгрейда (и перехода на msbuild vs2019) — перестало.
Испробывал уже кучу нагугленных заклинаний, но ничего не сработало.
настроил уже чтоб А генерил файл с xml-док в папку Б\bin
пробовал в Б подцеплять
<Content Include="bin\A.xml" /> — так копирует, но в bin\bin\A.xml (то есть в подпапку bin папки bin, а надо в bin\A.xml )
<Content Include="A.xml" /> — так копирует в корень, а надо в bin\A.xml
Есть у кого-нибудь рабочий способ как скопировать файл-ресурса в output папку (туда куда dll-ки) при паблише проекта?
Здравствуйте, MadHuman, Вы писали:
MH>Есть у кого-нибудь рабочий способ как скопировать файл-ресурса в output папку (туда куда dll-ки) при паблише проекта?
Не могу воспроизвести вашу ситуацию. У меня копируется всё.
Что сделал:
— в VS2022 создал 2 проекта библиотек для .Net 6
— в первом включил генерацию XML документации
— во втором указал первый в Dependecies
Собираю второй — XML документация от первого лежит в его (второго) bin
Аналогично делаю dotnet publish — в папку для publish попадает документация от первого.
Солюшен прикладываю
Посмотрите, может что-то я просто не учел
Re[2]: скопировать в outputdir фал xml документации
МР>Что сделал: МР>- в VS2022 создал 2 проекта библиотек для .Net 6 МР>- в первом включил генерацию XML документации МР>- во втором указал первый в Dependecies
МР>Собираю второй — XML документация от первого лежит в его (второго) bin МР>Аналогично делаю dotnet publish — в папку для publish попадает документация от первого.
МР>Солюшен прикладываю МР>Посмотрите, может что-то я просто не учел
Спасибо Михаил за информацию!
у меня ситуация несколько отличается
— собираю в VS2019 и таргет net48 (но я перевёл ваш солюшен на этот таргет — это роли не сыграло — после сборки хмл-док от А подтягивается).
— проект Б — это WebApplication (и не sdk-style) и при сборке-то хмл док файл в bin оказывается,
но при отработке publish (при помощи скрипта с запуском msbuild и таргетом — /T:Package) такая проблема и происходит.
то есть отрабатывает сборка и в bin хмл файл оказывается, но затем в папке куда финальный паблиш происходит — нет.
можно наверно разобраться что там изменилось (после апгрэйда студии и мсбилда), но пока видится что проще добавить в паблиш явную таску по копированию файла.
Re[3]: скопировать в outputdir фал xml документации
Здравствуйте, MadHuman, Вы писали:
MH>можно наверно разобраться что там изменилось (после апгрэйда студии и мсбилда), но пока видится что проще добавить в паблиш явную таску по копированию файла.
Я вас понял.
Стало интересно самому и я полез посмотреть.
Получилось следующее.
1. Да, вы правы, при выполнении цели Package, все файлы XML-документации от связанных сборок в публикацию не включаются (т.е. в bin есть, а в папке публикации и в пакете — нет).
Этим можно управлять с помощью опции ExcludeXmlAssemblyFiles (и похоже именно она, точнее — её значение по умолчанию, поменялась при апгрейде)
В публикацию попадут все файлы XML-документации от всех связанных сборок и проектов.
2. Если описанное выше поведение вас не устраивает, а хочется чтобы копировался только 1 файл от одной сборки, это можно сделать через коллекцию Items под названием FilesForPackagingFromProject.
Правда, эта коллекция, похоже очищается в процессе сборки, поэтому её нужно добавить в нужную точку Pipeline сборки (после компиляции, но перед тем как будет произведено копирование для упаковки). Вот тут указывается, что нужно добавить инъекцию в Pipline перед целью CopyAllFilesToSingleFolderForPackage, но, похоже (статья немного старая) с тех пор некоторые цели изменили название и такой цели в MSBuild для VS2022 я не нашел, зато нашел CopyAllFilesToSingleFolderForMsdeploy.
Поэтому решение выглядит так — добавить в проект фрагмент:
МР>P.S. Буду признателен, если опишите результаты ваших экспериментов
Спасибо Михаил! вариант с ExcludeXmlAssemblyFiles пожалуй не буду использовать, мне необходим только один конкретный хмл-док файл.
А вот следующее найденное вами решение с AddXml сработало! спасибо!
таргет CopyAllFilesToSingleFolderForPackage действительно старый, и ранее часть моих попыток была зацепиться на него, но он не работал.
я это уже тоже выяснил за счет просмотра лога мсбилда, и новый таргет — CopyAllFilesToSingleFolderForMsdeploy
но осталось непонятно как лучше поступать в следующем случае (с хмл-док это был один пример),
допустим в проекте А есть ресурс Р (длл-ка) которая в итоге идет в output сборки и нужна там где используется А.
В проекте Б, нужно тоже чтоб зависимость для А — ресурс Р, также пошла в уже его output, и далее и в паблиш Б.
не очень хороший вариант (но понятный) — это в Б явно настроить копирование Р, и по вашему сэмплу выше — и добавление и в папку при паблише.
но как-то не очень хорошо так делать, явно должен быть способ лучше, чтоб описав что А использует зависимость Р, затем она автоматом включалась и в output Б и при паблише Б тоже подхватывалась..
буду признателен, если вдруг есть идеи и сможете прокоментировать..
Здравствуйте, MadHuman, Вы писали:
MH>буду признателен, если вдруг есть идеи и сможете прокоментировать..
Честно говоря, я не особо специалист и тоже сужу только по тому, что нашел в логах и в самих файлах .targets.
У меня получилось следующее:
— чтобы что-то попало в пакет, оно должно быть в коллекции FilesForPackagingFromProject
— этак коллекция заполняется в несколько приемов и из разных источников, но вообще всё сводится к: сам результат сборки проекта, файлы контента в проекте, референсы текущего проекта и сателитные (как я понимаю, это ресурсы локализации) сборки
— для нас самое близкое это файлы, которые строят на основе references. Этот список формируется из коллекций ReferenceCopyLocalPaths и ReferenceComWrappersToCopyLocal
— в свою очередь список ReferenceCopyLocalPaths заполняется в цели ResolveAssemblyReferences, которая, по сути просто вызывает задачу ResolveAssemblyReference
Собственно, уже из названия понятно, что в список ReferenceCopyLocalPaths попадают те сборки, для которых стоит свойство CopyLocal установлено в True. Причем попадают, как сборки на которые наш публикуемый проект ссылается явно, так и те, у которых в зависимых проектах CopyLocal тоже установлено в True.
Помимо самих сборок туда еще попадают одноименные файлы с расширением .xml и .pdb. Но этот список можно расширить, добавив в свойство AllowedReferenceRelatedFileExtensions (хотя и не думаю ,что это чем-то поможет)
Причем, судя по всему, даже имя не обязательно должно совпадать. Главное, чтобы в списке расширений было ваше.
Сейчас проверил:
— добавил в проект, на который я ссылаюсь (ClassLib) произвольный файл (TextFile1.txt),
— настроил для него Copy to Output Directory == Always
— а потом просто в свойство AllowedReferenceRelatedFileExtensions добавил его расширение (только в конце файла проекта — чтобы не перетереть существующее значение):
Здравствуйте, Михаил Романов, Вы писали:
МР>Здравствуйте, MadHuman, Вы писали:
MH>>буду признателен, если вдруг есть идеи и сможете прокоментировать.. МР>Честно говоря, я не особо специалист и тоже сужу только по тому, что нашел в логах и в самих файлах .targets.
Михаил, у меня оффтоп-вопрос: как вы во всём этом разбираетесь?
Я в своё время пытался забороть простую вроде проблему — и так и не понял, куда копать. Пытался прочитать все эти .props и .targets — дохлое дело, какой-то птичий язык, документации по которому не существует.
Как вы понимаете, что и куда нужно добавлять?
Задачу я, кстати, так и не решил: у меня есть солюшн, в котором есть C# проект и С++ проект.
Шарповому проекту нужна .dll/.so, которая является результатом сборки C++ проекта. Она должна лечь рядом с шарповой .dll, но я так и не смог этого добиться.
Костыль, который я применил — это post-build event для шарпового проекта, который тупо делает копию файла с известным именем.
Выглядит крайне коряво, увы.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[7]: скопировать в outputdir фал xml документации
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Михаил Романов, Вы писали:
МР>>Здравствуйте, MadHuman, Вы писали:
MH>>>буду признателен, если вдруг есть идеи и сможете прокоментировать.. МР>>Честно говоря, я не особо специалист и тоже сужу только по тому, что нашел в логах и в самих файлах .targets. S>Михаил, у меня оффтоп-вопрос: как вы во всём этом разбираетесь?
рекомендую отличный видос https://youtu.be/6GG_4Mrt2Fs
после него у меня ясное понимание многих вещей возникло
документация кстати есть
S>Задачу я, кстати, так и не решил: у меня есть солюшн, в котором есть C# проект и С++ проект. S>Шарповому проекту нужна .dll/.so, которая является результатом сборки C++ проекта. Она должна лечь рядом с шарповой .dll, но я так и не смог этого добиться. S>Костыль, который я применил — это post-build event для шарпового проекта, который тупо делает копию файла с известным именем. S>Выглядит крайне коряво, увы.
аналогичную задачу я решил у себя так — к таргету копирования в оутпут прицепил свой таргет копирования
Message — это таска по выводу сообщений в билд лог, удобно для отладки — что таргет запустился, и значения пропертей выводить
<Target Name="CopyCustomFilesToOutput" AfterTargets="CopyFilesToOutputDirectory" >
<!-- copy sqlite3 from Libraries to output, вместо PredBuildEvent c запуском xcopy -->
<Message Text="TargetDir=$(TargetDir) OutputPath = $(OutputPath) OutDir=$(OutDir)" />
<Copy SourceFiles="$(SolutionDir)Libraries\SQLite\sqlite3.dll" DestinationFolder="$(TargetDir)" SkipUnchangedFiles="true" />
</Target>
Здравствуйте, Sinclair, Вы писали:
S>Михаил, у меня оффтоп-вопрос: как вы во всём этом разбираетесь?
Не очень быстро, увы, и не всегда успешно...
На самом деле, сам MSBuild не очень сложный. Это, конечно, не Lisp (надеюсь меня не закидают за такое сравнение), но в нем базовых конструкций очень немного:
— targets
— tasks
— properties
— items + items metadata + metadata transformation
— conditions (условное выполнение)
Если в общих чертах понять как они между собой связаны, то читать MSBuild становится гораздо проще.
Более того, на самом деле документация по MSBuild вполне себе приличная. Но она именно документация, т.е. когда вы знаете что искать и вам просто нужны детали. Типа какие есть встроенные метаданные у items.
Я не смотрел полностью виде Никиты, на которое дали ссылку в соседнем ответе, но в свое время я делал похожее введение (только у меня как обычно — более академично и более тяжеловесно) для коллег в EPAM и там основы с небольшими демками укладывались примерно в часовой рассказ (я, кстати, хотел свои записанные лекции повыкладывать во вне, но мне сказали "не позорь контору" и я не стал).
В общем, если познакомиться с неким базовым Tutorial, то дальше будет гораздо проще.
S>Как вы понимаете, что и куда нужно добавлять?
Ну, честно признаюсь, что далеко не всегда я таки понимаю, что делать в MSBuild, даже с учетом имеющейся практики
Обычно выручает следующее:
1. Знание как строятся связи между targets в тех MSBuild, которые поставляет MS. А именно, что в property вида XXXDependsOn записываются те targets, от которых зависит текущая:
Таким образом можно начать раскручивать с конца — что от чего зависит
2. Просто офигенный инструмент от Кирилла Осенкова — MSBuild Binary and Structured Log Viewer!
Просто ставите себе этот вьюер, затем запускаете msbuild с нужными параметрами и ключом /bl (запись бинарного лога)
И дальше всё как на ладони
— какие выполнялись targets (а какие из-за условий пропускались — т.е. вы все равно видите полный pipeline)
— какие параметры передавались в tasks
— какие на выходе этими задачами менялись коллекции items или properties
— ...
+ Поиск по всему
+ Переход к исходному коду
В общем даже отладчик (он был раньше — можно было подключиться к MSBuild 4.0 и прямо из студии по MSBuild файлу ставить точки останова и смотреть что и как менялось в runtime!) не нужен — ну только сами tasks отлаживать.
S>Выглядит крайне коряво, увы.
Да я бы не сказал, если честно. Pre- и PostBuild targets используются регулярно.
Но если это OpenSource проект и дело не сильно горит, я могу попробовать на досуге глянуть. Вдруг найду более красивое решение (хотя передача результатов между проектами не сильно мне знакомая тема. Я обычно или правил существующие стандартные проекты — инъекции в процесс сборки, или выяснить какие параметры есть, ... — ну или писал свои отдельные MSBuild для, например, сборки всего солюшена с какой-то постобработкой.)
Re[6]: скопировать в outputdir фал xml документации
МР>Честно говоря, я не особо специалист и тоже сужу только по тому, что нашел в логах и в самих файлах .targets.
Спасибо Михаил!
вы навели меня на следующий вариант как сделать
<ItemGroup>
<None Include="..\Libraries\SQLite\sqlite3.dll">
<!-- здесь токо рут, нельзя в подпапку, тк тогда в OutDir копируется тоже в эту подпапку! -->
<Link>sqlite3.dll</Link>
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
</None>
</ItemGroup>
то есть, если добавить в проект А итем и ему CopyToOutputDirectory, то файлик появится в аутпут проекта Б (куда подцеплен А), и даже автоматом подтянется при паблише проекта Б!
вариант хороший, но недостаток что все такие итемы будут отображаться в корне проекта, в целом на это конечно можно забить, но хорошо было бы их поместить в папочку.
но в папочку помещать нельзя (вот так <Link>deps\sqlite3.dll</Link> ) так как в этом случае они в папке аутпута будут не в корне, а в подпапке (то есть будет такой bin\deps\sqlite3.dll )
Link отвечает за виртуальное имя (и путь) к итему, которое отображается в обозревателе проектов.
я думал над вариантом как бы сделать таргет который как-то проапгредит (или трансформирует) итемы такого типа (или с нужными метаданными), но пока не придумал как.. и можно ли так..
МР>>Честно говоря, я не особо специалист и тоже сужу только по тому, что нашел в логах и в самих файлах .targets. MH>Спасибо Михаил! MH>вы навели меня на следующий вариант как сделать
MH>вариант хороший, но недостаток что все такие итемы будут отображаться в корне проекта, в целом на это конечно можно забить, но хорошо было бы их поместить в папочку.
Это решается добавлением метаданного TargetPath.
Попробуйте вот так:
<ItemGroup>
<None Include="deps\sqlite3.dll">
<!-- здесь токо рут, нельзя в подпапку, тк тогда в OutDir копируется тоже в эту подпапку! -->
<Link>sqlite3.dll</Link>
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
<TargetPath>sqlite3.dll</TargetPath>
</None>
</ItemGroup>
MH>я думал над вариантом как бы сделать таргет который как-то проапгредит (или трансформирует) итемы такого типа (или с нужными метаданными), но пока не придумал как.. и можно ли так..
Можно.
Попробуйте вот такой вариант:
MH>>вариант хороший, но недостаток что все такие итемы будут отображаться в корне проекта, в целом на это конечно можно забить, но хорошо было бы их поместить в папочку. МР>Это решается добавлением метаданного TargetPath.
супер! сработало. в принципе тогда задача полностью решена, файлики можно собрать красиво в одну папочку (чтоб в обозревателе проектов отображалось красиво),
в аутпут будут ложиться в его корень как и надо,
автоматом при подцеплении ссылки на проект в других проектах, эти файлики будут в его аутпут ложиться и при паблише тоже!
ещё раз большое спасибо Михаил, ваши советы и идеи очень помогли!
MH>>я думал над вариантом как бы сделать таргет который как-то проапгредит (или трансформирует) итемы такого типа (или с нужными метаданными), но пока не придумал как.. и можно ли так.. МР>Можно. МР>Попробуйте вот такой вариант: МР>
а вот эту идею не понял..
чем это лучше явного включения итема через ItemGroup?
может я выразился неточно, идея была — раз итемы из ItemGroup копировались не туда куда надо (про TargetPath я ещё не знал), то
сделать трансформацию, чтоб взять имеющиеся итемы и создать (либо обновить их) для GetCopyToOutputDirectoryItems итемы с откорректированным Link-ом (удалить из него директорию)..
но при наличии TargetPath это уже не нужно.
ну только для каких-то уже более хитрых случаев
Re[9]: скопировать в outputdir фал xml документации
Здравствуйте, MadHuman, Вы писали:
MH>супер! сработало. в принципе тогда задача полностью решена, файлики можно собрать красиво в одну папочку (чтоб в обозревателе проектов отображалось красиво),
Отлично!
MH>ещё раз большое спасибо Михаил, ваши советы и идеи очень помогли!
Обращайтесь Иногда бывает здорово отвлечься от рутинных задач на что-то эдакое.
MH>а вот эту идею не понял..
Это, видимо, я невнимательно прочитал ваше сообщение.
Я почему-то подумал (сейчас перечитал сообщение, и сам не знаю почему...), что вы хотите, чтобы элементы, которые вы хотите добавить в Output в проекте не показывались вообще, а просто лежали в какой-то папочке и в тихую добавлялись бы в Output.
Этот вариант как раз это и делает, перед target, которая непосредственно выполняет копирование в Output, он заполняет коллекцию _ThisProjectItemsToCopyToOutputDirectoryAlways (кстати, это мой косяк. Вам, судя по тому, что вы указывали условие копирования PreserveNewest, нужна коллекция _TransitiveItemsToCopyToOutputDirectoryPreserveNewest), которая после использования для формирования списков копирования сразу же очищается.
Re[8]: скопировать в outputdir фал xml документации
Здравствуйте, Михаил Романов, Вы писали: S>>Выглядит крайне коряво, увы. МР>Да я бы не сказал, если честно. Pre- и PostBuild targets используются регулярно. МР>Но если это OpenSource проект и дело не сильно горит, я могу попробовать на досуге глянуть. Вдруг найду более красивое решение (хотя передача результатов между проектами не сильно мне знакомая тема. Я обычно или правил существующие стандартные проекты — инъекции в процесс сборки, или выяснить какие параметры есть, ... — ну или писал свои отдельные MSBuild для, например, сборки всего солюшена с какой-то постобработкой.)
Проект совершенно открытый: https://github.com/evilguest/linq2d. В нём Tests и Benchmarks зависят от SauvolaBinarizeCPP.
Корявость — в том, что гвоздями прибивается информация о конкретных файлах в конкретных проектах. И что я не понимаю, как сделать так, чтобы выполнение этого копирования зависело от успешности сборки. Всё, на что меня хватило — разруливание копирования .dll/.so в зависимости от платформы, на которой выполняется сборка.
Нормальное решение — чтобы зависимый проект автоматически находил все output-ы С++-зависимостей и тащил из за собой. В том числе, к примеру, и .pdb.
Именно так всё работает для дотнетных зависимостей.
А для C++ — проектов эта очевидная штука из коробки не работает, и как её заставить работать у меня ума не хватает разобраться.
Зависимости между плюсовыми проектами резолвятся благодаря как раз тому, что С++ гадит свои результаты не в фолдер проекта, а на уровень солюшна. В итоге все .dll и .exe случайно оказываются в одном и том же месте.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[9]: скопировать в outputdir фал xml документации
Здравствуйте, Sinclair, Вы писали:
S>Корявость — в том, что гвоздями прибивается информация о конкретных файлах в конкретных проектах. И что я не понимаю, как сделать так, чтобы выполнение этого копирования зависело от успешности сборки. Всё, на что меня хватило — разруливание копирования .dll/.so в зависимости от платформы, на которой выполняется сборка.
Понял.
Попробую глянуть. Результат обещать не могу, но разобраться будет самому и интересно и полезно.
Если (или как только) будут какие-то результаты, дам знать (ну или сразу пришлю PR).
S>Именно так всё работает для дотнетных зависимостей.
Похоже, там тоже всё не совсем гладко... Но не буду утверждать, сам до конца в своих догадках не уверен.
В общем, постараюсь ближе к концу декабря посмотреть (как раз будет время + было желание в этом году поразбираться со схожей задачей — как работает Common Project System, которая, можно, сказать, построена на MSBuild).
Re[9]: скопировать в outputdir фал xml документации
Здравствуйте, Sinclair, Вы писали:
S>Всё, на что меня хватило — разруливание копирования .dll/.so в зависимости от платформы, на которой выполняется сборка.
А зачем? Копируй все что есть в подпапочки runtime, в соответствии с правилами стандартного загрузчика dll.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[10]: скопировать в outputdir фал xml документации
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, Sinclair, Вы писали:
S>>Всё, на что меня хватило — разруливание копирования .dll/.so в зависимости от платформы, на которой выполняется сборка.
НС>А зачем? Копируй все что есть в подпапочки runtime, в соответствии с правилами стандартного загрузчика dll.
Хм, интересная идея. Но всё же для полноты ощущений хотелось бы избавиться от магии вида "я знаю, что там уровнем выше лежат возможно нужные мне данные".
Да, и ещё — под линухом проект собирается при помощи gcc, и результат попадает не в папку $(SolutionDir)\x64\$(ConfigurationName)\, а в $(ProjectDir)../SauvolaBinarizeCPP/x64/$(ConfigurationName)/.
Поэтому непонятно, как сделать "всё, что есть". Мне надо какой-то магией узнать OutputDir другого проекта.
UPD: ну, и тащить "всё, что есть", тоже не надо. C++ генерит ещё и .lib (хз как оно там под линухом называется), и ещё какой-то .ext.
Они мне нафиг не упали в дотнетном проекте.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Хм, интересная идея. Но всё же для полноты ощущений хотелось бы избавиться от магии вида "я знаю, что там уровнем выше лежат возможно нужные мне данные". S>Да, и ещё — под линухом проект собирается при помощи gcc, и результат попадает не в папку $(SolutionDir)\x64\$(ConfigurationName)\, а в $(ProjectDir)../SauvolaBinarizeCPP/x64/$(ConfigurationName)/. S>Поэтому непонятно, как сделать "всё, что есть". Мне надо какой-то магией узнать OutputDir другого проекта.
НС>Посмотри https://github.com/libgit2/libgit2sharp.nativebinaries , может поможет
Посмотрел, пока ничего не понял. Вижу, что они тащат cодержимое одних фолдеров в другие: https://github.com/libgit2/libgit2sharp.nativebinaries/blob/master/nuget.package/build/net46/LibGit2Sharp.NativeBinaries.props
Впрочем, я вообще не понимаю, что и как они собирают — в корне лежат .sh и .ps1, которые, судя по всему, вызывают какой-то cmake. Как это всё интегрируется с msbuild — .
S>>UPD: ну, и тащить "всё, что есть", тоже не надо. C++ генерит ещё и .lib (хз как оно там под линухом называется), и ещё какой-то .ext. НС>Все что есть имелось в виду под все таргеты, а не писать условия когда что копировать.
Простите, я не понимаю эту фразу. Что такое "под все таргеты"?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[9]: скопировать в outputdir фал xml документации
S>Корявость — в том, что гвоздями прибивается информация о конкретных файлах в конкретных проектах. И что я не понимаю, как сделать так, чтобы выполнение этого копирования зависело от успешности сборки. Всё, на что меня хватило — разруливание копирования .dll/.so в зависимости от платформы, на которой выполняется сборка.
в чем корявость включение инфы о каждом файле зависимости в проект?
после этого, автоматически проекты которые зареференсили ваш будут получать эти зависимости. как раз то что нужно.
и я не стал).
.