I am wondering if there is a way to synchronize the build numbers (20080213.1) without using the BuildNumberOverrideTarget where I would have to generate my own build number? I basically want to use the default/built-in tfs buildnumber generator but want to access it to align my assembly versions with it. Can this be done and is it a sensible way to do it this way?
相关问题
- Visual Studio 2019 - error MSB8020: The build tool
- Getting error: File extension specified '.webt
- Using TFS command line tf.exe how can I copy a rep
- TFS Power tools Migrate doesn't actually migra
- Is It possible to build asp.net core project using
相关文章
- Build errors of missing packages in Visual Studio
- Is it possible to do a “destroy history” in TFS?
- Copy different file to output directory for releas
- How do I make a TeamCity build appear in the TFS B
- TFS vs. JIRA/Bamboo/SVN [closed]
- Why doesn't my .tfignore file ignore my packag
- Why doesn't AutogenerateBindingRedirects work
- Is it possible to create a docker container from T
What you are asking for is very sensible and there are a number of ways to achieve this.
Personally, when I do this I don't like to check the files in to version control that have the build server generated number in them - it just introduces too many head-aches when merging code across branches but also I like a known version number to be used when a developer does a workstation build vs a proper build server derived assembly to make it really easy to tell them apart.
For more information on how I like to do it, take a look at the TFS Build Recipies wiki:
or my blog post on the topic
Hope that helps,
Martin.
Yes you can. At some point, possibly at AfterGet, you can use the BuildNumber and create a custom task to update the AssemblyInfo.cs files in your source code.
We've hooked into AfterGet and caused our target to be dependant:
Our VersionAssemblies Target pulls all of the AssemblyInfo.cs files from $(SolutionRoot):
checks them out:
edits them and replaces the file version with the $(BuildNumber):
and then checks the files back in:
For the replacement of the file versions I use the File.Replace task that comes with the Microsoft SDC tasks on CodePlex.
Also note, that if you have a build that is triggered on a checkin, when checking in the AssemblyInfo.cs files, make sure the comment includes $(NoCICheckinComment) as this causes TFS not to trigger another build otherwise you'll end up in an infinite build loop.