I am relatively new to tfs. I am creating msbuild logfiles during a build, but they are not getting moved to the drop location.
I am attempting to move a teambuild from 2010 to 2013. Due to versioned namespaces, I recreated the workflow template from a fresh default from the tfs server. The build is successful and the binaries are placed in the drop location via custom activity.
MSBuild is used four times on the workflow. Each has a unique LogFile name and use the same LogFileDropLocation. I get the binaries without the logfiles in the drop location. Using a diagnostic build, I do see that LogFileDropLocation has the correct drop location. However, my log files remain on the agent and do not get moved to the drop.
In the 2010 build, I get binaries and four logfiles in the drop location.
My question is, should Microsoft.Teamfoundation.Build.Workflow.Activities.MSBuild handle the copy/move of the log files, as I suspect, or later in the workflow? MSDN and the several books I have don't actually discuss how msbuild handles the logging. I am hoping someone knows specifically how MSBuild handles the logfile.
You need to put the XML files in your project and mark them as Content. They will be copied to the bin folder as output.
Example: Create a new project in visual studio. Them create an empty .xml file in the root of the project under source control. Right click and mark it as Content. Build the project.
You should see the bin folder has been created and the .xml file has been copied to that location.
This output is considered "compiled" or "generated" even though it is a copy. You may want to do some build processing to add parameters later.
When calling the MSBuild utility you can add parameters and have MSBuild handle the log file the way you want. I don't know the TFS workflow you've described so see how you could add that there.
You command can look something like this:
MSBuild.exe /target:Build Solution.sln /filelogger /fileloggerparameters:LogFile=C:\path\to\file\build.log;Verbosity=normal
Loggers are explained here (under Switches for Loggers): https://msdn.microsoft.com/en-us/library/ms164311.aspx
Verbosity is explained here: https://msdn.microsoft.com/en-us/library/microsoft.build.framework.loggerverbosity.aspx
Related
We currently use TFS 2010 for controlling some of our .NET projects.
I'd like to know whether it's possible to provide some kind of versioning within TFS for a specific folder on a network share for example.
The idea being is to control release packages (zips) for every release we do. As this bit is done by some other person (not technical and he doesn't use Visual Studio or any tech tool), it'd be great to streamline the process of versioning the zip files for every release.
Technically speaking:
We've setup this folder \servername\releasezips and every time I drop a file named release.zip, it would automatically commit (push) this file to the TFS server (no comments needed) and furthermore, once the file contents change (meaning that someone dropped another version of the file in there), the system would again push the file to TFS, but with a following version.
Is this possible somehow? I've seen somewhere that I could programatically have some extra control over TFS, using REST API.
Thanks in advance!
Thanks for your tips, Daniel and PatrickLu-MSFT.
As I said, I did want something straighforward, some kind of control similar to what box.com provides, where you associate a local folder on your machine with the cloud. So, once you drop files in the local folder, the small box client synchronizes it along with the cloud. If access the box.com, I can see the different versions of that specific file.
So what I did was, I've created a small .NET app to monitor the folder and any new files dropped in there would get checked in to our TFS server, by using the tf command line (of course ignoring work items or comments).
So, progamatically within the .NET app, it builds up the tf required commands for processing and versioning the recently dropped files and therefore, executes them.
By the way, I could have used the Team Foundation API in order to do the same job, but it would demand way more effort.
Cheers
According to your description, you want to commit/check in files during the build/release pipeline.
It's not a recommend way to check-in generated build files and modify source code during a build pipeline. If you really want to do this, you could edit the build workspace files and use tf commands in custom activity and call the powershell eq:
cd $env:BUILD_SOURCESDIRECTORY
$TFFile = Get-Item "C:\Program Files (x86)\Microsoft Visual Studio 1x.0\Common7\IDE\TF.exe"
$tfOutput = [string]( & $TFFile.FullName checkin /noprompt /override:"***NO_CI*** New version is $newVersion." /comment:"***NO_CI*** New version is $newVersion." 2>&1)
Another way is installing TFS Power Tool and use the Windows PowerShell Cmdlets to check in the files. Refer to this link for more details: PowerShell and TFS: The Basics and Beyond
For version the dropped files, you could take a look this similar question: TFS Build Copy to Versioned Folder
Basically, you have to customize build definition with custom activity and based on build.buildnumber variable to generate/create .zip file.
We are using TFS for maintain file versions of our database.
We do not have any .NET application in our Source Control; only HTML and supported CSS files only.
Is it possible through TFS Build Automation process to create Zip package and Deploy the package to drop location?
Note: We Do not have any .NET project or solutions only need to deploy folder(with HTML and supported files) in zip format.
I somewhere read that TFS build definition compulsorily needs .SLN files to have build project.
We don't want to build anything or test anything
Just want to create zip and deploy same to drop location.
I have tried some tweaking of Build Definition.
But in New Build definition in process tab it asks me for Items to build, where my selection is restricted to .NET supported files only.
You will need to create a custom MSBuild project file (.proj) to perform the work that you need. You can test this file locally in the command line and then when it is ready, you can point the Build process at it.
This is a good starting point for you http://www.developerfusion.com/article/84411/customising-your-build-process-with-msbuild/
The MSBuild Community Tasks (https://github.com/loresoft/msbuildtasks) contains a Zip task which should make the job a lot easier.
Judging by your description, you are using 2010 or later. What I would do is to create a custom build template that does all of what you are looking for. If you start with default template obviously you would want to remove all of the compile and test activities and replace it with the zip and copy it to the binaries directory (From there it will be moved to the drop). You could do 1 of two things for the solution file requirement, create a fake solution file in the workspace and use that knowing it won't be compiled. Or you could, in the template, remove the Argument BuildSettings which is the object that contains the solution file and configurations.
I'm using TFS 2012 to automate a build of a solution which contains multiple windows services and two web applicaitons.
I've used the guide I found here to customize the build process template so that the windows services are put in a folder structure that I like. Specifically:
\dropserver\droproot\MyApp\BuildNumber\
\Service1
\Service2
\Service3
\Service4
This works great, but unfortunately it doesn't work for web applicaitons. If I used the same strategy for those, I just get the contents of /bin for each web app, rather than the full site contents.
MSBuild typically uses the web application targets to handle this, but for some reason, this doesn't work when you customize the build as I have. I no longer get the _PublishedWebSites folder in the build output. (I'm guessing that's because I cleared our the OutDir property of the MSBuild task.)
Has anybody done something like this and gotten it to work with web applications as well?
I think I can help with this, it looks like in the build targets that the published websites folder isn't created if the OutDir is the same as the OutputPath.
So this isn't perfect, but if you add the following into the csproj file in the first property group, you'll get everything deployed into "\bin\deploy\" including the _PublishedWebsites folder
<DeployOnBuild>True</DeployOnBuild>
<OutDir>bin\deploy\</OutDir>
With a bit of customization, this solution ended up working for me:
http://www.edsquared.com/2011/01/31/Customizable+Output+Directories+For+TFS+2010+Build.aspx
Basically, did what that link recommended, but also leveraged a new solution configuration (which I called TeamBuild) rather than conditional property definitions.
I believe the key to making this all work was the passing of the outputDirectory as the TeamBuildOutDir argument to MSBuild. Embedding this variable reference in the OutDir or OutputPath variable was allowed Team Build to build to the correct staging location and then automatically copy files from that location to the drop folder.
I'm going to take this a little futher and get rid of the whole _PublishedWebSites thing, but that will be done entirely in the build workflow.
EDIT: TFS 2013 supports this natively with a simply build configuration option:
Take a look at this thread as this post as well.
Team Build: Publish locally using MSDeploy
Since you need all the files for your web projects, you need to trigger the publishing process, and by tweaking the destination of that process, you can have all of your files copied where you need them.
I think option (2) from his answer will work for you.
I hope that helps.
As I can see in your reference link, it will just compile and package the binaries. It does not deploy the website by the steps mentioned in that.
If you want to get the .html, .css, .js etc. under the _PublishedWebSites folder, you need to do a Web Deployment. This manually we can do by clicking the publish option from right click menu of your VS project and by selecting Publish Method as File System.
But, since you need to automate this in your build and drop it in custom drop folder, you may need to manipulate your MSBuild script by calling a AspNetCompiler task. You can get more information on this at the MSDN link. By specifying the TargetPath while you call this target you can get your Web files deployed at the appropriate custom drop folder.
Happy Scripting.
Have you check this blog, this solved my problem where I wanted customized TeamBuild Ouput Directory.
Customizable O/P with TFS 2013
Customizaable O/P with TFS 2012 and .NET Framework 4.5
We have installers referencing a wixlib file to get some common functionality. The wixlib is built in another solution then moved to a folder within that solution. When we try to build the installers with a TFS build, we get an error from light.exe:
light.exe: The system cannot find the file '..\..\..\Core\Common\assemblies\v1.0\Common.Wix.wixlib' with type 'Source'.
Our regular projects can reference \assembiles\v1.0, since we have some other common assemblies stored there. How do we get WiX to recognize this location during build?
You are referencing wixlib directly. So as far as I understand the TFS build process, it should be added to TFS project of your solution. TFS project shouldn't be dependent on the output of another non-dependent solution. It is at least bad practice. And in any case you can't guarantee this output would be generated before your project build on server.
As far as I remember, TFS build creates separate folder for each build and gets sources there. So your solutions are no longer on the same folder hierarchy level.
One more point in favor of explicitly copying wixlibs into your installer project: versioning - in this case any bugs made in the common library will not immediately break all projects that reference it. And you can gradually upgrade and test every project. Can you imagine auomatically downloading new version of any 3rd party dll on every build? Any change in that dll will immediately break your application even if changes are not critical to you.
Since the shared component and the active solution are in two separate projects in TFS, the workspace must be setup so that the relative paths for references remain intact. The easiest way to do this is to set your Build Agent Folder structure in Workspace in your TFS Build to have $(SourceDir) represent your root. However, don't change your Source Control Folder - that stays the same.
For example, say you have the following structure:
-TFS
|-SharedComponents
||-MyComponents
|-ProjectArea
||-MyProject
You would want to have the following two items in the build Workspace:
Source Control Folder Build Agent Folder
---------------------------------------------------------------------------------
$/ProjectArea/MyProject $(SourceDir)\ProjectArea\MyProject
$/SharedComponents/MyComponents $(SourceDir)\SharedComponents\MyComponents
This mimics the structure in TFS in your build folder, thus allowing all relative paths to remain intact.
One more note about this configuration: Since you have the shared components in another location, you may want to create a solution folder in MyProject and add the components that you are using to it. This will ensure they get pulled automatically when anyone loads your project from TFS - they won't have to go back and pull down the share components folder separately after discovering a build error.
In my TFS 2010 build definition, I call MSBuild on my own custom my.targets MSBuild project. It does all the compilation, testing, etc. that I need. Its log file is specified, as is a log drop location, and the log appears properly in that place. However I can't see it in the TFS Build Summary report. The "View Log File" link is grayed out. It seemed to work when the project I was building was a ".sln" file. What magic voodoo is baked deep in to the heart of the common MSBuild files to make this log link work properly, and how can I reproduce it?
You may find your answer in these posts from Jason Prickett:
TFS2010 – Changing The Way Build Information IS Displayed
TFS2010 – Customizing the Build Details View – Summary View
Important to note is that the MSBuild Log File will only appear if you enabled inside the build definition to copy output to the Drop Folder. If that option is disabled, the link will not appear in the build log view.