I want to use macros of current csproj such as ${TargetPath} $(TargetName),in vNext Build defination as part of vs build task property of MSBuild argument,to do some copy etc.
But I found it not work,in build log, the macros did not be change into the absolute path.
Is there any way to use these macros just like in csproj post-build event?I did not find description about this on msdn ,and I could not use it in each csproj,because we have more than one thousand project files, edit the prj file one by one is not good:(
Thanks alot for your help.
Update
I want each project only output its own assembly without any referenced assembly when build.But I can't change project file to modify the reference property "copy local" to false.
You just need to add it as MSBuild arguments:
If you mean you want to achieve the function in post-build event same as this question Visual Studio Post Build Event - Copy to Relative Directory Location. There is no such thing like post-build in vnext build.
You can add several steps to copy the assemblies (One step for one project) and specify the copy root in the step.Refer to this question Copy one file in target directory on deploy from visual studio team services
However, as you have mentioned there are thousand project files. You can create a powershell script and add it in the build definition to copy the files.
Related
How to create build definition for multiple solutions that have dependency?
Background here:
There are two solutions
Solution A is class library contains an object class 'ClassA'
Solution B is console program that use 'ClassA' by add dll reference generated by solution A.
I would like to server build both solutions using one TFS 2017 build definition.
It raise out error:
Main\Source\SolutionB\Program.cs (13, 13)
Main\Source\SolutionB\SolutionB\Program.cs(13,13): Error CS0246:
The type or namespace name 'SolutionA' could not be found (are you
missing a using directive or an assembly reference?)
How to config the build definition that SolutionB would know to use the dll generated from the build of SolutionA?
You should build your first project that will be used at second project as dll and than copy files to build artifacts; than publish your dlls to specific folder that you referenced in your second project and finally build your second project.
You can check this image that with similiar process, just in below image it is publishing artifacts to three diffrent location, in your case it should be one publish task.
This is one of the simple way; but if you use the project A for some other projects too you may want to use NuGet packages. I am going to describe this as solution 2.
Solution 2: You should create a Nuget packages by the artifacts of Project A. You can host your Nuget packages in custom source folder. Add your first project's package to your project as a reference. You don't need to do something extra just add a nuget restore task to your build definition. If you want, you can publish your first project as a nuget package during the build definiton. Please check how to restore and install neuget packages by build definiton.
When I create a build definition I have setup some source settings, example below:
Problem is I want it to trigger a build when someone checks into the Builds or Install folders, but the Includes folder is just some libraries and other items it needs. I don't want it to re-run when these libraries are changed. However I need to set them up here to make sure they are copied across to the Build drop server. Is there a way to copy across this Includes folder without forcing a build trigger when someone checks in to this folder?
There are 2 things to do to approach this.
First you need to get your source folders into a build centric layout, this will help to eliminate as much overlapping as possible.
If you need a particular shared folder that shouldn't trigger a build, then don't include it in the source mappings, instead add a script to download the files to your workspace as an early part of the build.
The example will need updating for your visual studio version, and you should pass the sources Directory to the script.
REM %1 represents the Sources directory
REM Compute variables
SET TfExe="%ProgramFiles(x86)%\Microsoft Visual Studio 10.0\Common7\IDE\TF.exe"
REM SET TfExe="C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\TF.exe"
Set RefPath="$/TFS BUILDS/Shapes/Main/Includes"
Set localPath="%~1\Includes"
REM set the Drive Letter for this build
Set Localdrive=%localPath:~1,2%
%Localdrive%
cd %1
REM Map the folders
%TfExe% workfold /map %RefPath% %localPath%
REM Get the required content
%TfExe% get %RefPath%
REM Unmap the folders
%TfExe% workfold /unmap %RefPath%
There is no easy way to do this. As you've discovered, the source settings do double-duty, they define the set of files needed for the build that are downloaded and the set of files that trigger a CI.
I would argue this isn't a problem, if the Includes are used in your build, then I would want to kick off a new build when they change, to ensure that the change didn't break anything in the build process.
Use the special keyword ***_NO_CI*** in your checkin into the Includes directory.
See this post for further details.
The default behavior of TFS Build Server is copy all output, dlls, exes to the folder C:\Builds\{Build_Agent_Number}\{Team_Project_Name}\{Build_Controller_Name}\Binaries. I have customized the build process, not to copy to that folder but instead copy it to another, let say C:\Builds\{Build_Agent_Number}\{Team_Project_Name}\{Build_Controller_Name}\Sources\Some_Folder\Some_Sub_Folder.
The build process works as expected but the problem is all tests don't run. I debugged the build process template and found that it could not find test dlls. I want to know how can I specify the test dll location in the testsettings file or in the build process template.
You can set it on Find Test Assemblies activity in you Build Process Template workflow. It locates a little below the middle of the process.
Navigate to Find Test Assemblies activity inside Run MSTest for Test Assemblies.
Pree F4 to bring up the properties windows then change MatchPattern to the root path that contains assemblies you want to test. For example, String.Format("{0}\{1}", MyCustomAssembliesPath, testAssembly.AssemblyFileSpec)
So, I'm new to TFS build definitions - and the RA team at my company asked how to deploy a project that I built. In this case, a Windows Service project.
When I compile from Visual Studio, the "bin" directory has all the files I need... including copying a ".bat" file that is set to "copy local".
Anyway, the last step of the default "Build Definition" is "Run MSBuild for Project"... but that seems to just stick every DLL in the entire solution into an output directory.
Am I missing something? ... how do I get the build to:
Only build a single project - not the entire solution.
Put all the files that would be in the "bin" directory into the output directory.
When you're editing the Build Definition you can specify just a single project if you wish. By default TFS Build should put everything in the Build Drop that you typically find in your bin directory.
If you find the build is missing files that you expect to be there consult the MSBuild log that you can find linked from the TFS Build log. You can also run the TFS Build with Verbosity=Diagnostic when you queue up a build, which will cause the MSBuild log to contain much more detail.
Dylan Smith's answer was correct, and got me 90% there... the was a strange bug that some quick Googling found here: http://social.msdn.microsoft.com/Forums/uk/tfsbuild/thread/990fdd96-69bc-4e99-be0e-acc0874e022f
So, the solution is:
Do what Dylan said (pick the csproj file).
Remove the "Any CPU" part of the build... just target "Release" or "Debug" or whatever.
I have TFS 2010 and for one of the team project I have created the build definition (used default build template) and added the solution of one of the project. But when try to create build getting the following error:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Microsoft.Common.targets
(902): The command "if Debug == Debug copy
"C:\Builds\14\\\Sources\ServerObjects..\SharedInterfaces\bin\debug*.dll"
"C:\Builds\14\\\Sources\ServerObjects..\ServerObjects\bin\debug"" exited with
code 1.
I think you maybe has wrong folder structure on the source control, see my answer on similar question here
teambuilding and deploying a dll (e.g. wpftoolkit.extended.dll)
TeamBuild overrides the output folder so the bin\debug (or bin\release) folder won't exist. It collates the output into Binaries.
For your custom build step use the obj folder instead of bin as that'll be the same under both TeamBuild and the local machine build.