Reputation: 5690
Having asked question : https://stackoverflow.com/posts/comments/38046411?noredirect=1 I have decided perhaps I am looking at this problem the wrong way round.
The aim is to have a build definition which will when run redeploy the C# ASP.net application to the IIS service which is currently running.
I can manually update the files in the directory for the application but this is a manual process. I was looking at perhaps working out how to execute a batch script from a TFS 2012 Express Build Process xaml workflow file but then considered surely TFS build workflow xaml must have a build element for publish / package / deploy a ASP.net application to a IIS service / directory already and I simply need to know what it is called and how to do it?
Can anyone comment?
I am using Team Foundation Server Express 2012.
My TFS build process edit screen looks like this:
Upvotes: 1
Views: 468
Reputation: 39898
A Build in Team Foundation Server is based on an XAML workflow that contains all the steps that are taken when the build runs.
In your screenshot, you see at the top that you are using the Default Template (DefaultTemplate.11.1.xaml)
This file is located in a folder in souce control called Build Definitions. Editing this file and checking your changes in changes the build workflow.
The steps required to do this can be found here: Create and Work with a Custom Build Process Template.
Customizing your build process template is the recommended way of adding extra functionality to a build. As Dylan already pointed out, there is a lot of information in the community. The ALM Rangers have provided guidance but also a set of TFS build extensions that you can use out of the box.
Upvotes: 0
Reputation: 22245
I do this by using an InvokeProcess activity to call a powershell script. The powershell script is stored in TFS, and will execute my WebDeploy package (that is built either earlier in the same build, or in a separate TFS Build).
In TFS 2013 the default template (TfvcTemplate.12.xaml) contains hooks to easily call powershell scripts at various points in the workflow, without having to modify the workflow (you just specify the path in the build definition). I realize you aren't using 2013, so you'll still have to edit the workflow. I just wanted to point out that this is considered a best practice, and MS has recognized that in TFS 2013 by making it even easier to do this.
Upvotes: 2