I'd like to be able to automatically update the assembly version off all changed projects on a TFS check-in. We'd like to do this as part of our gated check-in so that developers don't have to remember to manually update those numbers on every check-in.
My current approach would be to:
Determine what projects contains changes on check-in
Check out the AssemblyInfo.cs in each project with changes
Increment the version number in each AssemblyInfo.cs file
Begin build process
I assume there is a way to accomplish this using a combination of PowerShell and customizing the TFS build template, but have little familiarity with either. Any help on the matter would be greatly appreciated.
Use the script located here as a pre-build script in your build template.
The script will change all AssemblyInfo.cs files that are found with the build number.
How to update assembly version of your projects using PowerShell scripts. A very good guide.
The answer is bit late but you can find a good guide here , Have a look into that
Related
We are still using an in-house TFS 2012 server but I'm now looking at moving to VSTS. I have a couple of questions though:
Years ago I customised our build process template to perform a number of additional tasks, and I was wondering if VSTS builds can be customised in a similar way, specifically to do what we currently do:
Run StyleCop
Change the version number in every AssemblyInfo.cs file in the solution prior to building (the major and minor numbers are specified in the build definition).
Run a batch file at the end of the build which runs an InnoSetup script to create a "setup.exe" file (the batch filename is againspecified in the build definition).
(The first two are (I think) DLLs that came from the now defunct tfsbuildextensions.codeplex.com site).
Second question: we currently have an in-house NuGet repository. Am I right in saying I could host this on VSTS instead? And will that be accessible both to VSTS builds and our dev team?
The newer build system is fully extensible. You can simply add "Command Line", "Batch File", or "PowerShell" tasks to run whatever commands you'd like during your build process. Any customizations you made to your XAML build process templates will have to be ported manually, but it's entirely possible that someone has created free extensions that are available to install from the VSTS marketplace that replicate the behavior you're seeking.
VSTS supports package management feeds. It's an extension and requires additional licensing, but the simple answer to your question is "yes".
I am trying to get the Source Version Changeset number from TFS. I am using a PowerShell script to add the AssemblyInformationalVersion. I have tried using $env:TF_BUILD SOURCEGETVERSION but this dosen't work it just return blank. We are using TFS 2012 with a custom build template calling the PowerShell scripts (http://www.colinsalmcorner.com/post/build-script-hooks-for-tfs-2012-builds)
I really want to keep everything within the PowerShell Script
No, this can't be achieved simply by an environment variable in a powershell script . You need to create a custom task, follow the steps below to have a try:
Get the latest changeset number in your TFS version control. You can
just get it by using TFS API. Please see this thread for
detailed information: Programmatically retrieve the latest changeset number available in a workspace
You can write another small program to modify your FileVersion field
in the .rc file be the changeset number you get in Setp1.
Or you can try the method descried by Ivan's answer in this question Versioning .NET builds
Add more similar quesitons in SO for your reference:
Getting TFS to put the changeset in the assembly version
TFS and msbuild version number with last changeset
Take control of assembly numbering during a tfs build
The answer is in the article you referred to(The Challenge 2 – Environment Variables).
When I created a script for a 2013 build to version the assemblies, I
relied on the fact that the 2013 build sets some environment variables
that you can use in your scripts.You can see I’m getting
$env:TF_BUILD_BUILDNUMBER. Well, in the 2012 workflow, these variables
aren’t set, so you have to add an activity to do it.
That's why $env:TF_BUILD SOURCEGETVERSION returns blank, so you just need to follow the steps in Challenge 2 to set it.
I am using VSTS vNext build system to build a C# solution.
Below you can see the settings for the NuGet Packager. The path to nuspec files is set to reference the .csproj files.
However this includes all .csproj files; I need to exclude test projects. Ignoring 'Core.Test.csproj' but still packaging 'Core.csproj'.
I have tried '*.csproj;-:!*test.csproj' and other combinations but have had no luck figuring this out! Does anyone know how the pattern matching works for vNext build?
**\*.csproj;-:**\*test.csproj should do it (no exclaimation point needed). If not, we may have a bug, and you should file it on GitHub.
The latest version (2.x) of the NuGet task in VSTS and TFS 2018 uses a different pattern for excluding packages. Now you use ! instead of -:.
So **\*.csproj;-:**\*.Test.csproj changes to **\*.csproj;!**\*.Test.csproj.
Full pattern matching documentation can be found here.
I'd like to check in assemblies to TFS source control after successful project build on TeamCity. Are there any elegant and easy way to do that?
I can create a command line step and run tf.exe with parameters, but then I need to provide credentials to connect to TFS, map the directories and finally do the check in.
The second option is to set up the powershell step, and use one of the cmdlets, but this requires installation of cmdlets on the build machine which I don't want to do.
Have you got any experience in such case? Maybe I can use the credentials used by TeamCity to get the sources, and do not map the directories but use the downloaded structure / sources?
This answers your question but it is not normally a good idea to commit binaries to your source control. You have a couple of choices.
Create a nuget package manually:Nuget Packages can be stored in a
shared folder. You can manually create a package in 5 minutes.
If your other projects are built using teamcity, check out artifact
dependencies in teamcity.
TF.exe commandline tool is the best feasible option for this scenario.
I'm trying to get continuous integration working using Hudson, Maven & Perforce (with an scm poll used to trigger each build)
One of the requirements is to automatically update POM snapshot version numbers following each successful build.
This is trivial using the Maven release plugin, but the act of checking in the newly versioned POMs triggers another build - which continues ad infinitum.
Is there any way of checking in version updates without triggering another build? There doesn't seem to be any way of excluding specific user checkins, specific changelists, or specific files when the scm poll makes the decision to rebuild.
This seems like a basic requirement - been doing it for years using Cruise Control / Ant / Perforce,
Cheers,
Mark
I have been contemplating a move to Hudson, but the inability to exclude specific files from the scm poll would be a deal breaker. Did you also ask this question on the Hudson mailing list?
users <at> hudson <dot> dev <dot> java <dot> net
The only workaround I can see from reading through the docs seems to be triggering builds based on p4 triggers, where you could then programmatically do whatever you want, but that doesn't seem to be a very simple approach.
I don't believe there is any way to configure Hudson to omit part of a Perforce workspace when polling. You may have better luck by setting up two different workspaces - one for build test using a default POM and one for your releases with the auto-updated release POM. The two workspaces could differ on just this one file and modifying the release POM would not trigger a new build.
Check out how to do individual file mapping in a workspace in the P4Guide.
Its possible to update the description of a changelist after it has been submitted, so if you build to a certain changelist number you can then update the description of that changelist to include your build number. This shouldnt trigger a new build.
What is "POM"?
You can have Hudson "Create or Update Label in Perforce" (see near the bottom of your project's configuration.) You could use that along with the BUILD_NUMBER environment variable that Hudson provides, giving you unique build numbers and stamped P4 labels of said build.
I have all tagging, ChangeLog updates, and packaging done by our checked in build code. This allows us to:
Create RC and appropriate tags without starting anther build
Allows us to debug all aspects of our build on any dev machine, not just those with Hudson.
Allows us to exactly recreate how a package, tag, etc was done in at any point in the past.
I had a similar problem checking in compiled src. I was able to find an alternative but i did consider the following.
In hudson specify a child folder of your project to poll. I.e. don't actually have hudson check out your project, just an incidental folder.
Add a shell script to check out your project proper.
Run you normal scripts.
check in your pom. The trick here is that the folder being polled won[t have changed at this point.
Not ideal, but works.
The perforce plugin has had polling masks for a while now. It's in the Advanced section under "View Mask".
Basically, you list a subset of files that you want polling to check for changes. Unfortunately there's no easy way to exclude files, so you'll have to create a list of file specs that specify everything BUT the file you want to exclude. So if the version is contained in a pom.xml, I would need to specify the files and directories that don't contain it.
For example, if your directory structure looked like this:
./pom.xml
./lib/
./src/
You would specify,
//depot/project/lib/...
//depot/project/src/...
as the view mask, and check the checkbox to use it only for polling. There are a few limitations with this feature, such as not being able to use '-' to exclude file specs, but it's still a workable solution for now.