I am attempting to follow the tutorial for CI with Azure and a Team Foundation Build Server located here, but am running into an issue with the configuration of the build configuration template XAML file, in Step 5. In trying to configure a new ConvertWorkSpaceItem, and add it to the modified build template TFS provides (TfvsTemplate.12.xaml) so that a custom script can be run on a TFS build agent, I attempt to set the property Workspace = "Workspace", but am given a compiler error: 'Workspace' is a type and cannot be used as an expression.
I've done some troubleshooting already, and the errors that have happened to others -- not scoping the CreateWorkSpaceItem, or using the wrong version of TFS or Visual Studio -- do not seem to be issues. I placed the logic correctly inside the "Run on Agent" block, so the scope should be right, and Visual Studio and my TFS Server are both running 2013. My only thought is that the instructions are out of date, and there is some other step that needs to be taken that I am missing. Any ideas?
EDIT:
Here are the parameters for the first failed convert item. The second failed Convert item is similar. The Input and Result variables are parameters defined by me for the workflow as part of the instructions for the tutorial. The error displayed is: "Compiler error(s) encountered processing expression "Workspace". 'Workspace' is a type and cannot be used as an expression."
ok this has come up a couple of times now, for TFS 2013.
Built in variables used to be available for
SourcesDirectory, Binaries Directory and Workspace
these are no longer available in TFS 2013 you now have to use
Microsoft.TeamFoundation.Build.Activities.Extensions.WellKnownEnvironmentVariables
to access these.
Getting the workspace is a little more complicated but if you assign some local variables you should be able to get the workspace object.
Declare local variables for sourcesDirectory (string) and buildDetail (IBuildDetail) and workSpace(Workspace) set their scope to the whole workflow
Create an GetEnvironmentVariable Activity and set its Result value to be sourcesDirectory and use Microsoft.TeamFoundation.Build.Activities.Extensions.WellKnownEnvironmentVariables.SourcesDirectory.
Repeat the same for buildDetail = WellKnownEnvironmentVariables.BuildDetail
Create an assign task for the workSpace object, set this one as
workSpace =
"[buildDetail.BuildServer.TeamProjectCollection.GetService().GetWorkspace(sourcesDirectory)]"
This should then give you a Workspace object to use.
note: syntax might be slightly out.
To compliment the removal of these variables MS have added a new Activity
GetLocalPath
which may be of use to you instead
Related
I have two team builds created in VS 2013 - Dev and Test - using the TfvcTemplate.12.xaml build process template. Both builds also use a custom .proj file defined in the process tab "Build/Projects" parameter.
Dev is set to Continuous Integration to build on each check-in. For the Test build, I'd like to update to a particular version.
When firing the build manually, in the parameters tab, I have successfully been able to specify a Changeset in the "Get Version" option. (C9999)
1) I'd like to eventually fire this build from command line, so is it possible to pass this in as a /msBuildArgument instead? e.g. /p:GetVersion=C9999
(I've tried this, and it successfully passes GetVersion to my .proj files, but it does not override the iBuildDetail.SourceGetVersion, which I think is what needs to happen to tell MSBuild what version to get from source control.)
2) Would using the "Label", "BuildId" or "BuildNumber" be better options, and if so, can I specifiy them as /msBuildArguments?
I have found a few related posts, but these offer suggestions that don't seem directed to 2013, but rather 2010 and 2008.
This screenshot shows where I can successfully enter and build a specified changeset and what I'm attempting to pass via arguments.
I found some buried documentation which indicates to prefix the label with an "L". Setting Get Version = "LlabelName" did the trick.
https://msdn.microsoft.com/en-us/library/gg490833.aspx#VersionSpecs
This is helpful, but it seems the labels are tied the to the build's retention policy. For this reason, I'll be using Changesets to specify the version I want to get (build and deploy).
Also, I found a couple parameters to specify Changeset (or labels) to add to the TFSBuild start command I am executing from the command line:
/getOption:Custom /customGetVersion:C9999 (or LlabelName)
I have the following variables defined:
Now once a build is complete (the last step in the build process), I want to update the VersionRevision variable, basically increment it.
So I'm looking for an API I can call from C# and create a console application or a powershell script to edit the build definition (if I have to do this)?
You can use VSTS Rest API to update the variable value in Build Definition. Both Console Application and Powershell Script is OK for this.
If I understand correctly, you want to get these build variables and them assignment them as your version number.
After the build completes, update and increment the VersionRevision. It's not a good way and seems not available to achieve it.
In TFS build there is a $(Rev:.r) which means
Use $(Rev:.rr) to ensure that every completed build has a unique name.
When a build is completed, if nothing else in the build number has
changed, the Rev integer value is incremented by one.
Source: Specify general build definition settings
To version your assemblies you could just add an powershell script in your build definition, detail ways to achieve please follow this link from MSDN: Version your assemblies
And usually we only define and assignment variables with the Major and Minor version. If you want to change the value of them. You may need manually edit the build definition.
More related link about how to manage version numbers as part of your vNext builds.
vNext Build Awesomeness – Managing Version Numbers
Generate custom build numbers in TFS Build vNext
I want to build change set 3880 from my software using TFS 2010.
When I create a new build to the queue and set the parameter "Get Version" on the tab "Paramaters" to C3880 (or 3880 which should be the same), then TFS builds always the neweset sources (change set 3888) and not the requested 3880.
e.g. following http://blog.sublogic.com/2011/09/22/tfs-2010-building-an-older-changeset/1/
Is that a server problem or a configuration problem? Is there another place where someone could have set TFS to the latest sources (where?) ?
Best regards,
Stefan
The display in VS is buggy. It seems that the right parameter is processed to the build server, but VS shows "current change set". I built an older change set and the output is "older".
I am creating a custom process template in our TFS server.
I would like to execute the following line of during the process, to automatically modify the assembly's revision number in AssemblyInfo.cs based on the current MMDD:
File.WriteAllText(file, Regex.Replace(File.ReadAllText(file), "(?<=\[assembly: AssemblyFileVersion\(""[0-9]*.[0-9]*.[0-9]*.)[0-9]*(?=""\)\])", Function(m) DateTime.Now.ToString("MMdd")))
Unfortunately I cannot find out how to execute an arbitrary line of VB.NET code in the build process. There are no code activities called "execute", "run" etc.
I tried to hack it by inserting a lambda function into a WriteBuildMessage() call, but found that lambdas are disallowed:
(EDIT: after other problems with that expression were fixed, it now simply gives the error: "Statement lambdas cannot be converted to expression trees" - ergo I can't do what I'm trying to do here. If "File.WriteAllLines" was string instead of void then I could return it and be laughing.)
Is there a way I can execute an arbitrary line of VB.NET code as part of the build process?
Note: I got around it by adding a node to InvokeMethod directly on System.IO.File.WriteAllText, passing the Regex.Replace call as one of the parameters.
I'll leave the question open in case anyone can provide a direct answer to the original question.
As you mentioned yourself it is possible to use the "InvokeMethod" in order to somewhat execute a line of code.
What I would suggest is to create a custom activity where you can provide it with the parameters, such as the file name and file path.
In order to achieve this two main tasks are needed:
Include a custom build process template
Creating a custom activity
You either do this in your current solution or you create a whole new solution to handle your custom activities and process template.
Include Custom Build Process Template
Whether you choose to work on your current solution or a new one, it is important to have the Process Build Template included in a separate project.
The project needs to be an "Activity Library" which is found under installed (VS 2013):
Right-click solution -> Add.. -> New Project... -> Visual C# -> Workflow
In this project you add your process template that you have been working on, by adding it as an existing item and making it a link. This can be done by pressing the small arrow at the "add" button
When this is included you will need to include several references, which can be found here [1]
Creating Custom Activities
As for the Build Process Template all the custom activities needs a project to be build in. This is to ensure that when they are to be used it is simply referencing the project or including the dll.
This project also needs to be an Activity Library, where this time the activities are to be created.
An activity is a Code Activity and can be created by:
Right-click Project -> Add -> New Item... -> Visual C# Items -> Workflow -> Code Activity
And again this project needs several references in order to build, which can be found here[1]
References:
For more information and ideas take a look at this:
[1]: Ewald Hofman - Customize Team Build
You should not create this yourself. You should use the precreate TfsVersion activity built into the TFS Community Build Tools.
https://tfsbuildextensions.codeplex.com/wikipage?title=How%20to%20integrate%20the%20TfsVersion%20build%20activity&referringTitle=Documentation
This tool will do all of the heavy lifting and is supported by the Visual Studio ALM Ranger and MVP's.
We have a standard MSBuild project file that is used for our different deployment stages (pre-stage, stage, live, etc). Since each deployment stage is performed on a different server we introduced a server parameter called $SourceDatabaseServer and used this extensively in each of the targets inside the project file. Note: This database server name could be different from the server name on which the build is run.
To assist us with the customization of this parameter, we created a response file for each deployment stage and subsequently defined a value for this parameter in the response file, e.g. /p:SourceDatabaseServer=SRC_DB_NAME.
This worked fine, until we created a new deployment stage in which this value had to be the current computer name. So we thought by using the $(COMPUTERNAME) reserved property in the response file (/p:SourceDatabaseServer=$(COMPUTERNAME)), this would do the trick, but it seems like this value is interpreted literally by MSBuild, and we consequently get an error that server $(ComputerName) could not be found.
Interestingly, when the $(COMPUTERNAME) property is used directly in the proj file it works, but as stated above, we do not necessarily want to use the computer name in all the cases.
Is there a way to still use the $(COMPUTERNAME) property in the response file and get MSBuild to interpret this correctly?
What if you use %COMPUTERNAME%?
$(VAR) is the syntax for variable expansion when you're "inside" the MSBuild system, but coming from the outside, I believe you'd have to use the shell environment variable expansion syntax, %VAR%.