Здравствуйте.

Имеется некоторый набор проектов, которые используют сторонние утилиты. Эти утилиты складываются в папку /tools исполняемого проекта. На данный момент чехарда, ибо каждый exe проект имеет свою папку /tools с соотв. утилитами. Хотелось бы иметь единственное место, куда можно складировать утилиты и чтобы они копировались для всех исполняемых проектов. Таких проектов немного -- два или три -- поэтому можно все руками, но хотелось бы как-то автоматизировать это дело. Можно завести пустой проект и создать единую папку tools там, но тогда на выходе будет бесполезная dll. Кто как решает эту проблему?

Здравствуйте, Sharov, Вы писали:

S>Кто как решает эту проблему?
Нюгет + папка tools в пакете. В проект через .targets подрубаются.

Здравствуйте, Sinix, Вы писали:

S>Нюгет + папка tools в пакете. В проект через .targets подрубаются.
Лучше через .props

Здравствуйте, Codechanger, Вы писали:

S>>Нюгет + папка tools в пакете. В проект через .targets подрубаются.
C>Лучше через .props
Ага, вечно их путаю.

Здравствуйте, Sharov, Вы писали:

S>Здравствуйте.

S> Хотелось бы иметь единственное место, куда можно складировать утилиты и чтобы они копировались для всех исполняемых проектов.

mklink?

Здравствуйте, Sharov, Вы писали:

S>Здравствуйте.

S>Имеется некоторый набор проектов, которые используют сторонние утилиты. Эти утилиты складываются в папку /tools исполняемого проекта. На данный момент чехарда, ибо каждый exe проект имеет свою папку /tools с соотв. утилитами. Хотелось бы иметь единственное место, куда можно складировать утилиты и чтобы они копировались для всех исполняемых проектов. Таких проектов немного -- два или три -- поэтому можно все руками, но хотелось бы как-то автоматизировать это дело. Можно завести пустой проект и создать единую папку tools там, но тогда на выходе будет бесполезная dll. Кто как решает эту проблему?

/bin, /usr/bin

Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, Sharov, Вы писали:

S>>Кто как решает эту проблему?
S>Нюгет + папка tools в пакете. В проект через .targets подрубаются.

Создал нугет пакет, файлы находятся в /content/tools , в build добавил файл targets:

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <ItemGroup>
    <AvailableItemName Include="Tools" />
  </ItemGroup>
  <ItemGroup>
    <Tools Include="$(MSBuildThisFileDirectory)tools\*">
    </Tools>
  </ItemGroup>
  <Target Name="CopyTools" DependsOnTargets="CopyFilesToOutputDirectory">
    <Copy SourceFiles="@(Tools)"
          DestinationFolder="$(OutDir)\tools">
     </Copy>
   </Target>
</Project>

В файл проекта прописалось
<Import Project="..\packages\Tools.1.0.1\build\Tools.targets" Condition="Exists('..\packages\Tools.1.0.1\build\Tools.targets')" />

Никакого эффекта, файлы в проект в папку tools добавляются, но в outdir не копируются. msbuild лог выдает такое сообщение
7>Task "Error" skipped, due to false condition; (!Exists('..\packages\Tools.1.0.1\build\Tools.targets')) was evaluated as (!Exists('..\packages\Tools.1.0.1\build\Tools.targets')).

Все таргеты на месте.

ЧЯДНТ?

Здравствуйте, Sharov, Вы писали:

S>ЧЯДНТ?

Вроде всё правильно, но я сварщик ещё тот.

Я бы подсмотрел у fody или у любого другого похожего фреймворка.
Или просто использовал бы инструменты из tools без копирования.

Проблема кажись в самом файле, не в нюгете. Если по аналогии сделать — работает?

Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, Sharov, Вы писали:

S>>ЧЯДНТ?
S>

Два момента:
1) меня смущает вот это в логе msbuild:
7>Task "Error" skipped, due to false condition; (!Exists('..\packages\Tools.1.0.1\build\Tools.targets')) was evaluated as (!Exists('..\packages\Tools.1.0.1\build\Tools.targets')).

2) структура нугет проекта у меня такая:



В папке tools и находятся exe файлы. Я вчера кучу времени убил пока не понял, что tools зарезервирован нугетом. Я использовал contents, а не tools.

S>Или просто использовал бы инструменты из tools без копирования.

Это как?

Здравствуйте, Sharov, Вы писали:

S>Здравствуйте, Sinix, Вы писали:

S>>Здравствуйте, Sharov, Вы писали:

S>>>ЧЯДНТ?
S>>

S>Два момента:
S>1) меня смущает вот это в логе msbuild:
S>7>Task "Error" skipped, due to false condition; (!Exists('..\packages\Tools.1.0.1\build\Tools.targets')) was evaluated as (!Exists('..\packages\Tools.1.0.1\build\Tools.targets')).

Данный вопрос снимается, тут все нормально. Попробую печатать переменные, если безуспешно, то отладка скрипта.

Здравствуйте, Sharov, Вы писали:

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <ItemGroup>
    <ToolsDir Include="$(MSBuildProjectDirectory)\tools\**\*.*" />
  </ItemGroup>
  <Target Name="CopyTools" AfterTargets="CopyFilesToOutputDirectory">
    <Copy SourceFiles="@(ToolsDir)" DestinationFolder="$(OutputPath)tools\">
     </Copy>
    </Target>
</Project>

Собственно все, нугет копирует файлы в проект, т.е. создается папочка tools с файлами в директории проекта (также и в студии). При сборке все это дело копируется.
Минусы -- project wide, а не solution wide. Но это не страшно.

А вот реальный вопрос -- как это все дело автоматизировать? Т.е. при сборке сделать из данного проекта нугет файл, и импортировать этот нугет в другие проекты. Пока использую локальную нугет папку и вручную обновляю пакет.

Здравствуйте, Sharov, Вы писали:

S>Собственно все, нугет копирует файлы в проект, т.е. создается папочка tools с файлами в директории проекта (также и в студии). При сборке все это дело копируется.
Пряздрявляю! т.е. проблема именно в .props была, угадал?

S>Минусы -- project wide, а не solution wide. Но это не страшно.
Solution wide емнип был только в 2.0, в третьем нюгете убран.

S>А вот реальный вопрос -- как это все дело автоматизировать? Т.е. при сборке сделать из данного проекта нугет файл, и импортировать этот нугет в другие проекты. Пока использую локальную нугет папку и вручную обновляю пакет.

Извращенческий способ:
Ссылки заменить на локальный нюгет-фид
https://docs.nuget.org/ndocs/hosting-packages/local-feeds
сборку пакета — через post-build action.

Как сделал бы я: отдельный .sln, подтаскивать через nuget-фид от CI server-а.

Здравствуйте, Sharov, Вы писали:

S>Минусы -- project wide, а не solution wide. Но это не страшно.

А разве не получится сложить это в глобальную папку уровнем повыше, как и нугетовая папка packages рядом с SLN-файлом?

Здравствуйте, Mr.Delphist, Вы писали:

MD>Здравствуйте, Sharov, Вы писали:

S>>Минусы -- project wide, а не solution wide. Но это не страшно.

MD>А разве не получится сложить это в глобальную папку уровнем повыше, как и нугетовая папка packages рядом с SLN-файлом?

Ну как бы да, все файлы для проект будут дублированы из packages/ProgramTools/tools/, что не есть хорошо. Пока и так сойдет.

Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, Sharov, Вы писали:

S>>Собственно все, нугет копирует файлы в проект, т.е. создается папочка tools с файлами в директории проекта (также и в студии). При сборке все это дело копируется.
S>Пряздрявляю! т.е. проблема именно в .props была, угадал?

Я не очень разбираюсь в инфраструктуре msbuild. Для создания пакета я использовал Nuget Package Explorer. В build я добавил Tools.targets и xml выше. Возможно нужно было в props прописать itemgroup, а в targets соотв. target. Я все смешал, но это как бэ работает. Проблема была и там и там.

S>>Минусы -- project wide, а не solution wide. Но это не страшно.
S>Solution wide емнип был только в 2.0, в третьем нюгете убран.

S>>А вот реальный вопрос -- как это все дело автоматизировать? Т.е. при сборке сделать из данного проекта нугет файл, и импортировать этот нугет в другие проекты. Пока использую локальную нугет папку и вручную обновляю пакет.

S>Извращенческий способ:
S>Ссылки заменить на локальный нюгет-фид
S>https://docs.nuget.org/ndocs/hosting-packages/local-feeds
S>сборку пакета — через post-build action.

S>Как сделал бы я: отдельный .sln, подтаскивать через nuget-фид от CI server-а.

В некоторых наших проектах, которые я использую, через TeamCity так и сделано. Но у меня есть legacy, который в TeamCity пока не помещается (7 гб. всяческого ради 3 мб. кода). Т.е. в sln используется проект из другого sln и git репозитория(!), к тому же под моей веткой. И да, я все понимаю.

Здравствуйте, Sharov, Вы писали:

Paket-like NuGet with MSBuild

Здравствуйте, vorona, Вы писали:

V>Paket-like NuGet with MSBuild

Всё хорошо, но стандартный Manage packages for solution ссылки в .targets / .props не обновляет.
Т.е. сторонние нюгет-фиды, авторазруливание конфликтов версий, подключение пакетов из автодополнения и прочие плюшки студии идут лесом.

Здравствуйте, Sharov, Вы писали:


S>Я не очень разбираюсь в инфраструктуре msbuild. Для создания пакета я использовал Nuget Package Explorer. В build я добавил Tools.targets и xml выше. Возможно нужно было в props прописать itemgroup, а в targets соотв. target. Я все смешал, но это как бэ работает. Проблема была и там и там.

.props от .targets отличается тем, что nuget помещает props в начало файла проекта, а targets- в конец, что позволяет избежать редактирования проекта ручками(но не полностью