Используйте chr (13) для возврата каретки и chr (10) для новой строки
echo $clientid;
echo ' ';
echo $lastname;
echo ' ';
echo chr (13). chr (10);
Посмотрев на ваш комментарий еще раз, я понял, что исказил то, что вам действительно нужно. Это интересная проблема, с которой вы столкнулись.
Если вы не возражаете против редактирования самого файла проекта, вы можете довольно близко получить то, что хотите. Есть элемент FileWrites , который отслеживает все файлы, которые были записаны в процессе сборки. Чтобы начать экспериментировать с этим, отредактируйте файл проекта так, чтобы он имел эту AfterBuild цель
<Target Name="AfterBuild">
<Message Text="FileWrites: @(FileWrites)" Importance="high"/>
</Target>
Также есть некоторые проблемы с этим подходом
Вы можете подумать, что можете решить первая проблема с MSBuild: найти много ссылок на проекты и вывести элемент FileWrites после выполнения сборки. Это будет работать только в том случае, если файл оболочки proj был помещен в ту же папку, что и сам исходный проект, потому что все элементы внутри файла .csproj объявлены с относительным путем. Так что по большей части это так.
Вы можете обойти второе ограничение, используя задачу FindUnderPath, чтобы получить только файлы, помещенные в папку OutputPath .
Что вы могли бы сделать, но это тоже ненадежно, так это проверить OutputPath в начале сборки, а затем еще раз в конце сборки и посмотреть, что было добавлено. Допустим, вы поместили исходные файлы в элемент StartFiles, а в конце сборки поместили все файлы в элемент с именем EndFiles, который вы могли бы сделать:
<Target Name="SomeTargetHere">
<ItemGroup>
<FilesWritten Include="@(EndFiles)" />
<FilesWritten Remove="@(StartFiles)"/>
</ItemGroup>
<!-- Now FilesWritten contains the difference between EndFiles & StartFiles -->
</Target>
Короче говоря, я не уверен, есть ли хорошее решение, которое не включает ни настраиваемую задачу, ни настраиваемое средство ведения журнала: (.
Сайед Ибрагим Хашими
Моя книга: Внутри Microsoft Build Engine: Использование MSBuild и Team Foundation Build
Если вы используете задачу MSBuild , то вы можете получить файлы, которые были созданы с помощью вывода TargetOutputs. Вот пример
<MSBuild Projects="YourProject.csproj">
<Output ItemName="YourProjectOutputs" TaskParameter="TargetOutputs"/>
</MSBuild>
Таким образом, в этом случае, когда создается YourProject.csproj , созданные файлы будут помещены в элемент YourProjectOutputs .
Я создал недавно появилась запись в блоге, в которой более подробно рассказывается об этом: MSBuild: Как получить все сгенерированные выходные данные .
Саид Ибрагим Хашими
Моя книга: Внутри Microsoft Build Engine: Использование MSBuild и Team Foundation Build
Взгляните на мою предыдущую запись в блоге MSBuild: Find Many Project References . В этом посте я описываю, как создать файл MSBuild, который может извлекать значения для Reference ItemGroup. В вашем случае просто замените цель, которую я создал, на цель, которая заполнила элемент из всех файлов, найденных в OutputPath. Дайте мне знать, если вы хотите, чтобы я подробнее остановился на этом.
Что мы делаем для борьбы с этим сценарием, так это то, что каждая сборка создает каталог «Deploy» (вы можете называть его как хотите).
Каталог развертывания содержит только те исполняемые файлы и библиотеки DLL, которые необходимы для реального приложения (т. Е. Тестовые библиотеки DLL туда не помещаются). Каждый проект должен будет поместить в этот каталог свои «развертываемые» материалы (мы даже добавляем подкаталоги (например, Интернет, службы и т. Д.).)
Он дублирует некоторые биты, но позволяет вам получить доступ ко всем dll из сборки если они нужны.