TextTemplating target in a .Net Core project - visual-studio-2017

I have recently migrated a test project to .NET Core 2.0. That test project used text templates to generate some repetitive code. The previous project had a build target to generate all T4-templates before build. Therefore, the generated code is also not checked in into the VCS.
I had used this snippet in the project to ensure that templates are built:
<PropertyGroup>
<!-- Default VisualStudioVersion to 15 (VS2017) -->
<VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">15.0</VisualStudioVersion>
<!-- Determinate VSToolsPath -->
<VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>
<!-- Run T4 generation if there are outdated files -->
<TransformOnBuild>True</TransformOnBuild>
<TransformOutOfDateOnly>True</TransformOutOfDateOnly>
</PropertyGroup>
<!-- Import TextTemplating target -->
<Import Project="$(VSToolsPath)\TextTemplating\Microsoft.TextTemplating.targets" />
My first approach was to keep this fragment and copy it to the new .NET Core project file.
Inside Visual Studio, this works because apparently, VSToolsPath is set correctly. However, when I run the .NET Core SDK tools, as for example dotnet test (as I do on the build server), VSToolsPath maps to Program Files\dotnet\sdk\2.0.3 and there, the text templating targets cannot be found.
Because that did not work, I also tried to simply install the Microsoft.VisualStudio.TextTemplating package from Nuget but that has two problems:
it does not officially support .NET Core and installs for .NET 4.6.1 and
Nuget does not seem to install anything, so I cannot adjust the paths in the project file.

To support building T4 templates while building dotnet build you need to use Custom Text Template Host, which already exists for .NET Core (https://github.com/atifaziz/t5). To include it, add to your project in any ItemGroup this element:
<DotNetCliToolReference Include="T5.TextTransform.Tool" Version="1.1.0-*" />.
As Visual Studio already has it's own Text Template Host implementation, your added element should be conditioned only for .NET Core. For example:
<ItemGroup Condition="'$(MSBuildRuntimeType)'=='Core'">
<DotNetCliToolReference Include="T5.TextTransform.Tool" Version="1.1.0-*" />
</ItemGroup>
And at the same time you should condition out of .NET Core your settings for Visual Studio's Text Template Host, like this: Condition="'$(MSBuildRuntimeType)'=='Full'".
You should also add <Import Project="Sdk.targets" Sdk="Microsoft.NET.Sdk" Condition="'$(MSBuildRuntimeType)'=='Full'" /> before importing Microsoft.TextTemplating.targets to make everything work correctly with .NET Core csproj in Visual Studio.
If you need to be able to clean up all generated code, you should rename your templates from *.tt to *.Generated.tt, all the code will be generated under *.Generated.cs and it will be possible to filter these file out at dotnet clean action.
The complete example of what it will look like in your csproj:
<!-- T4 build support for .NET Core (Begin) -->
<ItemGroup Condition="'$(MSBuildRuntimeType)'=='Core'">
<DotNetCliToolReference Include="T5.TextTransform.Tool" Version="1.1.0-*" />
<TextTemplate Include="**\*.Generated.tt" />
<Generated Include="**\*.Generated.cs" />
</ItemGroup>
<Target Name="TextTemplateTransform" BeforeTargets="BeforeBuild" Condition="'$(MSBuildRuntimeType)'=='Core'">
<ItemGroup>
<Compile Remove="**\*.cs" />
</ItemGroup>
<Exec WorkingDirectory="$(ProjectDir)" Command="dotnet tt %(TextTemplate.Identity)" />
<ItemGroup>
<Compile Include="**\*.cs" />
</ItemGroup>
</Target>
<Target Name="TextTemplateClean" AfterTargets="Clean">
<Delete Files="#(Generated)" />
</Target>
<!-- T4 build support for .NET Core (End) -->
<!-- T4 build support for Visual Studio (Begin) -->
<PropertyGroup Condition="'$(MSBuildRuntimeType)'=='Full'">
<VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>
<!-- This is what will cause the templates to be transformed when the project is built (default is false) -->
<TransformOnBuild>true</TransformOnBuild>
<!-- Set to true to force overwriting of read-only output files, e.g. if they're not checked out (default is false) -->
<OverwriteReadOnlyOutputFiles>true</OverwriteReadOnlyOutputFiles>
<!-- Set to false to transform files even if the output appears to be up-to-date (default is true) -->
<TransformOutOfDateOnly>false</TransformOutOfDateOnly>
</PropertyGroup>
<Import Project="Sdk.targets" Sdk="Microsoft.NET.Sdk" Condition="'$(MSBuildRuntimeType)'=='Full'" />
<Import Project="$(VSToolsPath)\TextTemplating\Microsoft.TextTemplating.targets" Condition="'$(MSBuildRuntimeType)'=='Full'" />
<!-- T4 build support for Visual Studio (End) -->
If you don't want to rename your template files and you don't need to clean up them, then replace:
<TextTemplate Include="**\*.Generated.tt" />
<Generated Include="**\*.Generated.cs" />
with:
<TextTemplate Include="**\*.tt" />
And delete:
<Target Name="TextTemplateClean" AfterTargets="Clean">
<Delete Files="#(Generated)" />
</Target>
For more information see:
How to set up code generation on dotnet build:
https://notquitepure.info/2018/12/12/T4-Templates-at-Build-Time-With-Dotnet-Core/
How to set up code generation on build for Visual Studio and .NET Core csproj:
https://thomaslevesque.com/2017/11/13/transform-t4-templates-as-part-of-the-build-and-pass-variables-from-the-project/
The full example of the generation of multiple files from a single T4 template:
https://github.com/Konard/T4GenericsExample
Update:
GitHub.com/Mono/T4 is even better.

You are at the mercy of someone writing a port for dotnet core.
This is old: http://www.bricelam.net/2015/03/12/t4-on-aspnet5.html
Or use a different templating tool entirely, though of course I understand if that’s not an option.

Or just use T4Executer. You can set which templates to execute before build, after build or ignore specific templates. Works good with VS2017-19

To expand on Konard's comment of "Update: https://github.com/mono/t4 is even better."
Install Mono/T4 (dotnet-t4) as a tool
If you are running an Azure devops pipeline, you can add it as a step - see the first part of https://stackoverflow.com/a/60667867/1901857.
If you are building in a linux dockerfile, add this before you build (we were using .net 6 on alpine, but it should be fine with other distros and versions):
# you will see a warning if this folder is not on PATH
ENV PATH="${PATH}:/root/.dotnet/tools"
RUN dotnet tool install -g dotnet-t4
If you want to use the tool on your dev machine, instead of VS TextTemplating, run a one-off install from powershell (but every dev in your team will need to do this):
dotnet tool install -g dotnet-t4
Run t4 on build - dev machine and pipeline
dotnet-t4 is setup very similarly to t5 in Konard's answer
Option 1 - dotnet-t4 installed on your dev machine
Add this to your csproj file. No conditional settings required.
<!-- T4 build support for .NET Core (Begin) -->
<ItemGroup>
<TextTemplate Include="**\*.tt" />
</ItemGroup>
<Target Name="TextTemplateTransform" BeforeTargets="BeforeBuild">
<ItemGroup>
<Compile Remove="**\*.cs" />
</ItemGroup>
<Exec WorkingDirectory="$(ProjectDir)" Command="t4 %(TextTemplate.Identity)" />
<ItemGroup>
<Compile Include="**\*.cs" />
</ItemGroup>
</Target>
<!-- T4 build support for .NET Core (End) -->
Option 2 - use VS templating on your dev machine
If you don't want everyone to install the tool locally, you can still add conditional build steps to the project, as per Konard's answer. Note that Visual Studio is now 64-bit, so you can use MSBuildExtensionsPath instead of MSBuildExtensionsPath32:
<!-- T4 build support for .NET Core (Begin) -->
<ItemGroup Condition="'$(MSBuildRuntimeType)'=='Core'">
<TextTemplate Include="**\*.tt" />
</ItemGroup>
<Target Name="TextTemplateTransform" BeforeTargets="BeforeBuild" Condition="'$(MSBuildRuntimeType)'=='Core'">
<ItemGroup>
<Compile Remove="**\*.cs" />
</ItemGroup>
<Exec WorkingDirectory="$(ProjectDir)" Command="t4 %(TextTemplate.Identity)" />
<ItemGroup>
<Compile Include="**\*.cs" />
</ItemGroup>
</Target>
<!-- T4 build support for .NET Core (End) -->
<!-- T4 build support for Visual Studio (Begin) -->
<PropertyGroup Condition="'$(MSBuildRuntimeType)'=='Full'">
<VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>
<TransformOnBuild>true</TransformOnBuild>
<!--Other properties can be inserted here-->
<!--Set to true to force overwriting of read-only output files, e.g. if they're not checked out (default is false)-->
<OverwriteReadOnlyOutputFiles>true</OverwriteReadOnlyOutputFiles>
<!--Set to false to transform files even if the output appears to be up-to-date (default is true)-->
<TransformOutOfDateOnly>false</TransformOutOfDateOnly>
</PropertyGroup>
<Import Project="$(VSToolsPath)\TextTemplating\Microsoft.TextTemplating.targets" Condition="'$(MSBuildRuntimeType)'=='Full'" />
<!-- T4 build support for Visual Studio (End) -->

Related

Step into custom nuget c++ package

I am trying to release a C++ nuget package into our company Nuget feed. The problem is that we can't step into functions during debugging (F11). We need to be able to debug inside the package sources but it seems i cannot made it work.
I enabled in VS the option "Debug not only my code", included the generated vc110.pdb files in the package and finally added in the .nuspec the line
<repository type="git" url="http://xxxx" />
Unfortunately, VS17 does not step into the code of my package. We are pretty desperate and we really need a solution to this problem in order to make our toolchain leaner.
This is a C++ question so please do not link me to C#/.NET solutions because they don't work.
NOTE 1: When i pack with nuget i do not use the -Symbols option because it generates 2 packages and the second one cannot be pushed on our nuget feed (dupikcated package)
NOTE 2: I looked into the /SourceLink option but it seems to be supported only in C#
NOTE 3: I cannot use the .vcxproj when packing (it does not work, nuget says that i didn't give it any input file so i have to use my own .nuspec:
<package >
<metadata>
<id>x</id>
<version>1.0.2</version>
<title>$title$</title>
<authors>x</authors>
<projectUrl>yyy</projectUrl>
<description>static .lib</description>
<tags>native</tags>
<repository type="git" url="yyy" />
</metadata>
<files>
<file src="include\**\*.*" target="include" />
<file src="x64\**\*.lib" target="lib\x64" />
<file src="x64\**\*.pdb" target="lib\x64" />
<file src="build\**\*.*" target="build" />
</files>
</package>
NOTE 4: Ours GIT repo is on a Azure Devops TFS machine
NOTE5 : We are using VS17 but compiling with vc110 toolset (yeah know, don't comment on that please)
Thanks all

MSBuild-Magic in Visual Studio failes to correctly detect changed Properties for build process

In my C++ project Visual Studio (2017) fails to detect changes in a property value when I trigger a "build" (e.g. via F5 requesting a debugger start).
I want to be able to use the property pages dialog in visual studio to specify a path variable to another library.
The simplified versions are here. First I use a .targets file:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<ItemGroup>
<PropertyPageSchema Include="$(MSBuildThisFileDirectory)\overrideSettings.xml" />
</ItemGroup>
<PropertyGroup Condition="'$(myDir)' == ''">
<__my_IncludeDir>somewhere\include\</__my_IncludeDir>
</PropertyGroup>
<PropertyGroup Condition="'$(myDir)' != ''">
<__my_IncludeDir>somewhere_else\include\</__my_IncludeDir>
</PropertyGroup>
<ItemDefinitionGroup>
<ClCompile>
<AdditionalIncludeDirectories>$(__my_IncludeDir);%(AdditionalIncludeDirectories)</AdditionalIncludeDirectories>
</ClCompile>
<ResourceCompile>
<AdditionalIncludeDirectories>$(__my_IncludeDir);%(AdditionalIncludeDirectories)</AdditionalIncludeDirectories>
</ResourceCompile>
</ItemDefinitionGroup>
</Project>
And an .xml file for the settings:
<?xml version="1.0" encoding="utf-8"?>
<ProjectSchemaDefinitions xmlns="clr-namespace:Microsoft.Build.Framework.XamlTypes;assembly=Microsoft.Build.Framework">
<Rule Name="ProjectSettings_NugetDevOverride" PageTemplate="tool" DisplayName="Nuget Development Override" SwitchPrefix="/" Order="1">
<Rule.Categories>
<Category Name="myTest" DisplayName="myTest" />
</Rule.Categories>
<Rule.DataSource>
<DataSource Persistence="UserFile" ItemType="" />
</Rule.DataSource>
<StringProperty Name="myDir" Category="myTest" />
</Rule>
</ProjectSchemaDefinitions>
Now, this does work to some extent.
However, Visual Studio fails to correctly detect changes in the property variable defined on the property page.
I build the project -> 1 succeeded
I build the project again (F5) -> 1 up-to-date
I change the variable myDir using the property page; making it empty or setting a value, so that the other property group in the .targets file is triggered.
I build the project again (F5) -> 1 up-to-date This is wrong!
I re-build the project -> 1 succeeded with correctly used new property value.
Where is the problem in my setup? Can I explicitly add myDir as property to be checked before the build is marked as up-to-date?
I found one workaround: DisableFastUpToDateCheck
https://stackoverflow.com/a/36004494/552373
But this is horrible, since my real project is very large and the fast-up-to-date-check really helps.
Update 20171128:
I now also tried the following:
I build the project -> 1 succeeded
I build the project again (F5) -> 1 up-to-date
I change the variable myDir using the property page; making it empty or setting a value, so that the other property group in the .targets file is triggered.
I close Visual Studio and open it again. No file-save dialog popped up.
I build the project again (F5) -> 1 up-to-date This is wrong!
The fact, that even this does not work, points at a real problem with the FastUpToDateCheck in Visual Studio.
Does anyone have a further idea?

How to use the Web Publishing Pipeline and Web Deploy (MSDEPLOY) to Publish a Console Application?

I would like to use web deploy to publish a Visual Studio "Console" application to a folder on the target system.
I have had some luck, and have been able to produce something similar to what I need, but not quite.
I've added the following to the console .csproj:
added the following projectName.wpp.targets file
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" />
and I've added the following projectName.wpp.targets:
<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="4.0">
<PropertyGroup>
<DeployAsIisApp>false</DeployAsIisApp>
<IncludeSetAclProviderOnDestination>false</IncludeSetAclProviderOnDestination>
</PropertyGroup>
<ItemGroup>
<FilesForPackagingFromProject Include="$(IntermediateOutputPath)$(TargetFileName).config">
<DestinationRelativePath>bin\%(RecursiveDir)%(FileName)%(Extension)</DestinationRelativePath>
<FromTarget>projectName.wpp.targets</FromTarget>
</FilesForPackagingFromProject>
</ItemGroup>
</Project>
I then edit the .SetParameters.xml file as follows:
<parameters>
<setParameter name="IIS Web Application Name" value="c:\company\project" />
</parameters>
When I then deploy using the generated .cmd file, I get all the files deployed to C:\company\project\bin.
That's not bad, but I'd like to do better. In particular, I'd like to omit the "bin" folder and put all files in the "C:\company\project" folder, and I'd like to be able to specify the ACLs
Has anybody been able to work around these problems?
Ok, so here's the way how to omit the 'bin' folder.
First of all, I'd like to emphasize that all this msdeploy-related stuff is for web apps deployment, and 'bin' folder seems for me to be almost hardcoded deeply inside. So if you want to get rid of it - you have to do some dirty things. Which I did.
We'll have to change $(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets project a little bit, so it's better to change not it, but it's copy.
Steps:
1.Backup $(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets(alternatively, you could install MSBuild.Microsoft.VisualStudio.Web.targets package, redirect your csproj file to Microsoft.WebApplication.targets file obtained from package and work with it).
2. In the $(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplicaton.targets find the xml node which looks like <CopyPipelineFiles PipelineItems="#(FilesForPackagingFromProject)"(there are several ones of them, take the one from the line ~2570).
3. Comment the node out, replace with the custom one, so eventually it will look like:
<!--
<CopyPipelineFiles PipelineItems="#(FilesForPackagingFromProject)"
SourceDirectory="$(WebPublishPipelineProjectDirectory)"
TargetDirectory="$(WPPAllFilesInSingleFolder)"
SkipMetadataExcludeTrueItems="True"
UpdateItemSpec="True"
DeleteItemsMarkAsExcludeTrue ="True"
Condition="'#(FilesForPackagingFromProject)' != ''">
<Output TaskParameter="ResultPipelineItems" ItemName="_FilesForPackagingFromProjectTempory"/>
</CopyPipelineFiles>-->
<!-- Copying files to package folder in 'custom'(dirty) way -->
<CreateItem Include="$(OutputPath)\**\*.*">
<Output TaskParameter="Include" ItemName="YourFilesToCopy" />
</CreateItem>
<Copy SourceFiles="#(YourFilesToCopy)"
DestinationFiles="#(YourFilesToCopy->'$(WPPAllFilesInSingleFolder)\%(RecursiveDir)%(Filename)%(Extension)')" />
Then
4. Your projectName.wpp.targets don't have to have FilesForPackagingFromProject, so it will look like:
<!-- targets -->
<PropertyGroup>
<DeployAsIisApp>false</DeployAsIisApp>
<IncludeSetAclProviderOnDestination>false</IncludeSetAclProviderOnDestination>
</PropertyGroup>
<ItemGroup>
<!-- intentionally left blank -->
</ItemGroup>
</Project>
That's it. Worked for me(tm), tested. Let me be honest, I don't like this approach, but that was the only way I made it working in the needed way. It's up to you whether you'll use it in your project or not.
My opinion is not to use msdeploy here - it was not for you task.
Better to write msbuild-scripts from scratch or accept the 'bin' folder, and fight against the framework again once next customization is required.

Running unit tests from a .proj file with MSBuild

I want to run unit tests using MSBuild. Here is how I invoke msbuild today:
msbuild MySolution.sln
Instead, I want to use an MSBuild project file called "MyBuild.proj" like this:
<?xml version="1.0" encoding="utf-8"?>
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="3.5" DefaultTargets="Build">
<Target Name="Build">
<ItemGroup>
<SolutionToBuild Include="MySolution.sln" />
<TestContainer Include="..\Output\bin\Debug\*unittests.dll"/>
</ItemGroup>
</Target>
</Project>
And then call this command line:
msbuild MyBuild.proj
For some reason, when I do that the command succeeds immediately and the build doesn't even happen. I fear I must be missing something very obvious as I am new to MSBuild.
I suppose I really have 2 questions:
Why doesn't this even build my solution
Is the "TestContainer" element correct for executing my tests
Thanks!
You havent supplied any task to actually do anything,
inside your build target you need a call to an msbuild task, your example becomes:
<Target Name="Build">
<ItemGroup>
<SolutionToBuild Include="MySolution.sln" />
<TestContainer Include="..\Output\bin\Debug\*unittests.dll"/>
</ItemGroup>
<MSBuild Projects="#(SolutionToBuild)"/>
</Target>
this specifies what projects you actually want msbuild to build.
See:http://msdn.microsoft.com/en-us/library/vstudio/z7f65y0d.aspx for more details and the parameters it takes.
Thats part one.
As for part 2? what testing framework are you using? If using mstest id try wrapping the commandline mstest.exe in an msbuild exec statement to get it to run and execute the tests. See an example here:http://social.msdn.microsoft.com/Forums/en-US/msbuild/thread/cb87a184-6589-454b-bf1c-2e82771fc3aa

Copy all files and folders using msbuild

Just wondering if someone could help me with some msbuild scripts that I am trying to write. What I would like to do is copy all the files and sub folders from a folder to another folder using msbuild.
{ProjectName}
|----->Source
|----->Tools
|----->Viewer
|-----{about 5 sub dirs}
What I need to be able to do is copy all the files and sub folders from the tools folder into the debug folder for the application. This is the code that I have so far.
<ItemGroup>
<Viewer Include="..\$(ApplicationDirectory)\Tools\viewer\**\*.*" />
</ItemGroup>
<Target Name="BeforeBuild">
<Copy SourceFiles="#(Viewer)" DestinationFolder="#(Viewer->'$(OutputPath)\\Tools')" />
</Target>
The build script runs but doesn't copy any of the files or folders.
Thanks
I was searching help on this too. It took me a while, but here is what I did that worked really well.
<Target Name="AfterBuild">
<ItemGroup>
<ANTLR Include="..\Data\antlrcs\**\*.*" />
</ItemGroup>
<Copy SourceFiles="#(ANTLR)" DestinationFolder="$(TargetDir)\%(RecursiveDir)" SkipUnchangedFiles="true" />
</Target>
This recursively copied the contents of the folder named antlrcs to the $(TargetDir).
I think the problem might be in how you're creating your ItemGroup and calling the Copy task. See if this makes sense:
<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="3.5">
<PropertyGroup>
<YourDestinationDirectory>..\SomeDestinationDirectory</YourDestinationDirectory>
<YourSourceDirectory>..\SomeSourceDirectory</YourSourceDirectory>
</PropertyGroup>
<Target Name="BeforeBuild">
<CreateItem Include="$(YourSourceDirectory)\**\*.*">
<Output TaskParameter="Include" ItemName="YourFilesToCopy" />
</CreateItem>
<Copy SourceFiles="#(YourFilesToCopy)"
DestinationFiles="#(YourFilesToCopy->'$(YourDestinationDirectory)\%(RecursiveDir)%(Filename)%(Extension)')" />
</Target>
</Project>
I'm kinda new to MSBuild but I find the EXEC Task handy for situation like these. I came across the same challenge in my project and this worked for me and was much simpler. Someone please let me know if it's not a good practice.
<Target Name="CopyToDeployFolder" DependsOnTargets="CompileWebSite">
<Exec Command="xcopy.exe $(OutputDirectory) $(DeploymentDirectory) /e" WorkingDirectory="C:\Windows\" />
</Target>
<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="3.5">
<PropertyGroup>
<YourDestinationDirectory>..\SomeDestinationDirectory</YourDestinationDirectory>
<YourSourceDirectory>..\SomeSourceDirectory</YourSourceDirectory>
</PropertyGroup>
<Target Name="BeforeBuild">
<CreateItem Include="$(YourSourceDirectory)\**\*.*">
<Output TaskParameter="Include" ItemName="YourFilesToCopy" />
</CreateItem>
<Copy SourceFiles="#(YourFilesToCopy)"
DestinationFiles="$(YourFilesToCopy)\%(RecursiveDir)" />
</Target>
</Project>
\**\*.* help to get files from all the folder.
RecursiveDir help to put all the file in the respective folder...
This is the example that worked:
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<ItemGroup>
<MySourceFiles Include="c:\MySourceTree\**\*.*"/>
</ItemGroup>
<Target Name="CopyFiles">
<Copy
SourceFiles="#(MySourceFiles)"
DestinationFiles="#(MySourceFiles->'c:\MyDestinationTree\%(RecursiveDir)%(Filename)%(Extension)')"
/>
</Target>
</Project>
source: https://msdn.microsoft.com/en-us/library/3e54c37h.aspx
This is copy task i used in my own project, it was working perfectly for me that copies folder with sub folders to destination successfully:
<ItemGroup >
<MyProjectSource Include="$(OutputRoot)/MySource/**/*.*" />
</ItemGroup>
<Target Name="AfterCopy" AfterTargets="WebPublish">
<Copy SourceFiles="#(MyProjectSource)"
OverwriteReadOnlyFiles="true" DestinationFolder="$(PublishFolder)api/% (RecursiveDir)"/>
In my case i copied a project's publish folder to another destination folder, i think it is similiar with your case.
Did you try to specify concrete destination directory instead of
DestinationFolder="#(Viewer->'$(OutputPath)\\Tools')" ?
I'm not very proficient with advanced MSBuild syntax, but
#(Viewer->'$(OutputPath)\\Tools')
looks weird to me. Script looks good, so the problem might be in values of $(ApplicationDirectory) and $(OutputPath)
Here is a blog post that might be useful:
How To: Recursively Copy Files Using the <Copy> Task
Personally I have made use of CopyFolder which is part of the SDC Tasks Library.
http://sdctasks.codeplex.com/
The best way to recursively copy files from one directory to another using MSBuild is using Copy task with SourceFiles and DestinationFiles as parameters. For example - To copy all files from build directory to back up directory will be
<PropertyGroup>
<BuildDirectory Condition="'$(BuildDirectory)' == ''">Build</BuildDirectory>
<BackupDirectory Condition="'$(BackupDiretory)' == ''">Backup</BackupDirectory>
</PropertyGroup>
<ItemGroup>
<AllFiles Include="$(MSBuildProjectDirectory)/$(BuildDirectory)/**/*.*" />
</ItemGroup>
<Target Name="Backup">
<Exec Command="if not exist $(BackupDirectory) md $(BackupDirectory)" />
<Copy SourceFiles="#(AllFiles)" DestinationFiles="#(AllFiles->
'$(MSBuildProjectDirectory)/$(BackupDirectory)/%(RecursiveDir)/%(Filename)%
(Extension)')" />
</Target>
Now in above Copy command all source directories are traversed and files are copied to destination directory.
If you are working with typical C++ toolchain, another way to go is to add your files into standard CopyFileToFolders list
<ItemGroup>
<CopyFileToFolders Include="materials\**\*">
<DestinationFolders>$(MainOutputDirectory)\Resources\materials\%(RecursiveDir)</DestinationFolders>
</CopyFileToFolders>
</ItemGroup>
Besides being simple, this is a nice way to go because CopyFilesToFolders task will generate appropriate inputs, outputs and even TLog files therefore making sure that copy operations will run only when one of the input files has changed or one of the output files is missing. With TLog, Visual Studio will also properly recognize project as "up to date" or not (it uses a separate U2DCheck mechanism for that).