this is the problem im having :
The error message
error MSB3021: Unable to copy file "<filename>" to "<output location>". Access to the path '<output location>' is denied
occurs when the MSBuild Copy task cannot overwrite an existing read-only file.
Typically in Team Build this error will occur because (a) there seems to be an issue in MSBuild where the same file can get included more than once in the list of files to get copied, and (b) these files will typically be read-only in a Team Build since they are retrieved from version control (and not checked out). The workarounds for the issue depend on the version of Team Build (and MSBuild) you are using.
i found this solution:
Team Build 2008 / MSBuild 3.5
In MSBuild 3.5, an OverwriteReadOnlyFiles property was added that can be set to true to allow Copy tasks involved in the build process to overwrite read-only files in cases like the one outlined here. As such, a third workaround is possible in Team Build 2008 / MSBuild 3.5. Note that this workaround will only work for projects that use the 3.5 version of Microsoft.Common.targets - because of the multi-targeting feature available in MSBuild, this will not necessarily be every project built by Team Build 2008.
To set the OverwriteReadOnlyFiles property to true globally, you can either:
Add the text "/p:OverwriteReadOnlyFiles=true" to TfsBuild.rsp for your build definition, or
Add the following property group to TfsBuild.proj for your build definition.
<PropertyGroup>
<CustomPropertiesForBuild>OverwriteReadOnlyFiles=true</CustomPropertiesForBuild>
</PropertyGroup>
Can someone Guide me on how to implement this solution on TFS 2010 on my build ?
i don't know where :
TfsBuild.rsp
or
TfsBuild.proj
are located and how i can add the mentioned suggestions
TFSBuild changed significantly in TFS 2010, it is no longer MSBuild based and is instead Workflow based. There is no longer a TfsBuild.proj file.
If you are trying to overwrite read-only files, you are possibly doing something that is not according to best practices (as MrHinsh mentioned in the comments). If you are sure that what you are doing is appropriate then you either need to turn-off the read-only flag, or use a copy method that is able to ignore the read-only flag.
Related
I am working on configuring a XAML build definition for a .net solution (of another company) stored in TFS2015.
The solution uses Dll references from a software X, installed on the developers computers, but not present in the Build server. (FTS and Build servers are shared among many clients).
I have option to add the required Dlls in a folder along with the source code, but I do not have option to modify the .csproj files.
In the Build definition, I tried to add the following in the MSBuild arguments field :
/p:AdditionalLibPaths=$/[long tfs path here]/CommonDlls
/p:AdditionalLibPaths=$(SourceDir)/CommonDlls
but it is not working.
Ideally, I would like to specify a relative folder from the root of the source code.
(a static path might work but only for one build server and agent, which is not the objective of shared build).
Any ideas on how I can define this parameter ?
There is also option to add a prebuild script path. I can store a script file along with source code. Any pointers for how to write such script file ?
You do not really need a script.
There are two things to make this work.
The first step is making sure that the DLLs are downloaded to the Agent working folder, the simplest way is have the $/[long tfs path here]/CommonDlls mapped in the Build Workspace; this is specified in the Source Settings tab of the Build Definition. Be careful to use the $(SourceDir) token in the mapping (see here).
The second point is to use a proper reference to the downloaded folder: use the TF_BUILD_SOURCESDIRECTORY variable (see here for full list).
So, if you added a mapping like
$/[long tfs path here]/CommonDlls -> $(SourceDir)\CommonDlls
use $(TF_BUILD_SOURCESDIRECTORY)\CommonDlls.
It took me almost 20 trials to get the right one, it all started with how long it took that warning to consider all other directories, I could've ignored it but here's the warning first
C:\Program Files (x86)\MSBuild\14.0\bin\Microsoft.Common.CurrentVersion.targets(1820,5): Warning MSB3245: Could not resolve this reference. Could not locate the assembly "nameOfDllFile". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors.
and this is the argument that got it working
/p:ReferencePath="$(build.sourcesdirectory)\Binaries"
where Binaries is the equivalent to CommonDlls from the question, and it is all because of the vague documentation and differences between versions of MSBuild, mine is 14.0 (VS2015).
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
Is it possible to modify a web.config file in one of my projects during a Team Foundation Server build? Inside of my web.config file I have two setting keys: VersionNumber and BuildNumber.
Is it possible to change the value of BuildNumber based on the ID of the build in TFS?
Since you're using TFS 2013 you have an easier option than the old way of modifying the workflow - Use PowerShell.
If you're using the build template TfvcTemplate.12.xaml (which is the new default in TFS 2013), then you have some extra build definition parameters you can set to specify Powershell scripts to run. This way you just write a little bit of powershell code that gets the TFS Build Number (from an environment variable), then finds your web.config file(s) and changes them.
There is a sample script published in the TFS Community Build Extensions project that will do something very similar that you could modify. It finds all AssemblyInfo.cs files, then uses RegEx to modify them to update the build number based on the TFS Build number.
See the sample PS script here: https://tfsbuildextensions.codeplex.com/SourceControl/latest#Scripts/ApplyVersionToAssemblies.ps1
See some docs on how to modify the build to run PowerShell here: http://msdn.microsoft.com/en-us/library/dn376353.aspx
The answer is yes, though it's non-trivial. I've done this in the past using two methods.
Method 1: Use CodeActivities and alter the TFS Build workflow XAML file to include the new CodeActivity as a workflow step.
Here's an article on creating custom workflows with custom code activities (it's a little dated but still relevant):
http://blogs.msdn.com/b/jimlamb/archive/2010/02/12/how-to-create-a-custom-workflow-activity-for-tfs-build-2010.aspx
Basically, you create a new object that inherits from CodeActivity, create properties for your inputs (BuildNumber,VersionNumber, TargetFile), perform your actions on the TargetFile and save it. Then you wire up this new DLL with your activity to the TFS Workflow XAML, injecting your activity in the desired build step (post-build & pre-package in your case I bet to ensure xml transforms are applied).
Method 2:
Tag the desired properties onto the MSBuild invocation inside the TFS XAML file so they are passed in to MSBuild and available for your to use as $(BuildNumber) and $(VersionNumber). Then you can use MSBuild tasks to inject the properties into the file at the right time.
I'm using TFS Server 2010.
In my source I have a folder called BuildProcessTemplates. This has a child folder called Custom Assemblies.
Now, when the build runs, it happily loads the DLLs in the Custom Assemblies folder and does its thing.
I need to modify the .xaml file that defines the workflow of the build. If I double click on the .xaml file VS tries to open it but throws an error saying it can't find certain types that I know are defined in the DLL that is in the Custom Assemblies folder.
The workflow is told where to find these types when the build runs by Build Controller as it is defined as a property in the TFS Admin Console.
So, how on earth do I get VS to open my .xaml file properly? How do I let it know where to look for the DLL? I've tried moving all of the files in Custom Assemblies in to the same folder as the .xaml file, but that didn't help.
Clearly I'm missing something; I just don't have a clue what it might be.
You normally create a C# Project (Unit Test is easiest because it is pretty bare).
When you have you project you then need to:
Add the XAML as a File,
Add the Custom Activities DLL's as references.
Add the relevant TeamFoundation* references from the GAC (make sure the TFS version matches - 2010 = v10, 2012 = v11).
Also, I always open our TFS "Build Project" with VS version that matches our TFS Version, I find it keeps the number of problems down.
There's a great series of posts from Ewald Hofman here, that go through the process - I find it a bit dated, and that the Wrox Professional TFS 2012 book does a better job of explaining it, if you can get a copy.
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.