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.
Related
I have a solution containing a web application and multiple database projects. While using the old XAML definition, I can compile and generate the database deployment files in TFS. With the new definition introduced in TFS 2015, I can only generate the web application deployment files.
Here are parts of the log -
2016-10-28T22:14:48.6892904Z Build started 10/28/2016 4:14:48 PM.
2016-10-28T22:14:48.8883071Z 1>Project "E:\TFS\agent\_work\1\s\Test.Client.sln" on node 1 (default targets).
2016-10-28T22:14:48.8893071Z 1>ValidateSolutionConfiguration:
2016-10-28T22:14:48.8903071Z Building solution configuration "release|any cpu".
2016-10-28T22:14:49.0633142Z ##[warning]E:\TFS\agent\_work\1\s\..\Databases\Test\Test.DB.Test.sqlproj.metaproj(0,0): Warning MSB4046: Error reading project file "..\Databases\Test\Test.DB.Test.sqlproj": Could not find a part of the path 'E:\TFS\agent\_work\1\Databases\Test\Test.DB.Test.sqlproj'.
2016-10-28T22:14:49.0643150Z 1>Project "E:\TFS\agent\_work\1\s\Test.Client.sln" (1) is building "E:\TFS\agent\_work\1\s\..\Databases\Test\Test.DB.Test.sqlproj.metaproj" (2) on node 1 (default targets).
2016-10-28T22:14:49.0693159Z 2>E:\TFS\agent\_work\1\s\..\Databases\Test\Test.DB.Test.sqlproj.metaproj : warning MSB4046: Error reading project file "..\Databases\Test\Test.DB.Test.sqlproj": Could not find a part of the path 'E:\TFS\agent\_work\1\Databases\Test\Test.DB.Test.sqlproj'.
2016-10-28T22:14:49.0823182Z 2>Done Building Project "E:\TFS\agent\_work\1\s\..\Databases\Test\Test.DB.Test.sqlproj.metaproj" (default targets).
I could not find much information on the new build definition. Anyone can help?
Thanks
We figured out what is wrong with this. Our database projects are in another folder. We need to map the server path with the local path in the Build's repository. After added this, the database project can be built.
First double check the difference of your two definitions XAML and vNext.
And check the file path E:\TFS\agent\_work\1\s\..\Databases\Test\Test.DB.Test.sqlproj on the build agent, if there are the corresponding file.
And try to build your database project directly instead of building the whole solution to see if there are some useful info for troubleshooting.
Update
Tips:
You can also build MSBuild project (.*proj) files.
If you are building a customized MSBuild project file, we recommend you use the MSBuild step instead of the Visual Studio Build step.
Source Link: Visual Studio Build
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.
I am trying to produce artifacts with TFS 2015.
Everything works fine except it does not include my Web.config file, which is vital to our application.
How can I get TFS to include my Web.config file in the "contents" area of the "Publish Build Artifacts" step of our build?
I have tried:
Web.config
*.*.config
*.*.xml
**\.xml
These are working:
**\bin
**\Content
**\fonts
**\Models
**\Scripts
**\Views
I believe you can use *.config
Did you really want to exclude any files? If not ** should include everything in the root.
If you are trying to reproduce what you can do when publishing from Visual Studio the you need to pass the correct MSBuild options to create the msdeoloy .zip file. You can the. Mearly capture *.zip...
Enter: “/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation="$(Build.SourcesDirectory)"” in the MS Build arguments…
When you build the output should include the same output in a zip as is created from the VS ui. You can also pass publish profiles and other parameters.
I have a Visual Studio 2013 solution with the full Orchard source code. When I use "Publish..." on the "Orchard.Web" project in Visual Studio, it correctly publishes the site to the File System destination I've configured into the .PubXml file that I used.
However, if I build this site using Jenkins, the files do not get copied to the destination. I've created a separate PubXml file that is used by Jenkins.
In my Jenkins job, I have two Build steps of interest. The first uses the src\Orchard.sln file with a command line argument of /p:Configuration=Release. This runs correctly, and builds the entire solution.
The second Build step, immediately after, uses the Build File of src\Orchard.Web\Orchard.Web.csproj and these command line arguments:
/p:DeployOnBuild=true
/p:PublishProfile="D:\workspace\Site\trunk\src\Orchard.Web\Properties\PublishProfiles\Jenkins.pubxml"
/p:VisualStudioVersion=12.0
/p:Configuration=Release
/p:Platform=AnyCPU
/v:minimal
/nologo
/p:WarningLevel=1
With this, the build and deploy seems to work - but doesn't. Here are some lines from the build output:
Copying all files to temporary location below for package/publish:
obj\Release\Package\PackageTmp.
Auto ConnectionString Transformed obj\Release\Package\PackageTmp\Shapes\Scripts\Web.config into obj\Release\CSAutoParameterize\transformed\Shapes\Scripts\Web.config.
(... about 200 more "Auto ConnectionString..." lines...)
Finished: SUCCESS
No where does it actually copy the files to the destination defined in the PUBXML file.
In contrast, in Visual Studio, the output looks similar, but transforms only 4 config files and includes lots of "Publishing folder x" lines:
(...)
Transformed Modules\SH.GoogleAnalytics\web.config using ....
Copying all files to temporary location below for package/publish:
obj\Release\Package\PackageTmp.
Publishing folder /...
Publishing folder bin...
(etc.)
(I have installed the latest Windows Azure SDK for .NET on the Jenkins server.)
I have the same trouble,that work for me:
/t:Rebuild
/p:DeployOnBuild=true
/p:PublishProfile=Jenkins_Publish
/p:Configuration=Release
do not use /p:VisualStudioVersion=xxx
This is kind of old, but I actually just set up Orchard to be able to get built via command line and MSBuild. Here is what I did:
/p:VisualStudioVersion=12.0;PublishProfile="example-profile";DeployProjA=true;FrameworkPathOverride="C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\v4.5";Configuration=Release;PublishProfileRootFolder=c:\Workspace\src\Orchard.Web\Properties\PublishProfiles;Password=ExamplePass
Since you are using Orchard you want to make sure that only the Orchard.Web project gets published so do not use DeployOnBuild=true. This will attempt to deploy every web project in the solution, which is a lot for Orchard. Instead follow the guidelines here to see how to deploy only the web project: http://sedodream.com/2013/03/06/HowToPublishOneWebProjectFromASolution.aspx
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.