Deploy from a Team Foundation Server build to Web Site without specifying password in the build

In a previous article I explained how to deploy an ASP.NET Web Site from a TFS Build thanks to MSDeploy engine. One of the great complain you can have with this solution is the need to specify UserName and password in build configuration and the need to use the AllowUntrustedCertificate=true.

The problem of the certificate is the simpler of the two to solve, you just need to use a certificate that is trusted inside your organization or a certificate issued by a trusted certificate authority (es godaddy), instead of the default one that is generated by MsDeploy configuration in IIS. This is most an administrative stuff and I’m not going to cover it in this post.

The most annoying stuff is getting rid of the password. You should start configuring the deploy user for IIS using the same user that runs TFS Build, this will give to build user the permission to execute the deploy.

image

Figure 1: Give to the build user publish permission.

This is not enough, if you fire your bulid you probably will receive an authorization error.

C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\Web\Microsoft.Web.Publishing.targets (4255): Web deployment task failed. (Connected to the remote computer (“webtest1.cyberpunk.local”) using the Web Management Service, but could not authorize. Make sure that you are using the correct user name and password, that the site you are connecting to exists, and that the credentials represent a user who has permissions to access the site.  Learn more at: http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_USER_UNAUTHORIZED.)

The dreaded ERROR_USER_UNAUTHORIZED can frustrate you for long time, because it is not so easy to solve. First of all you should check if the Windows Authentication is enabled in IIS configuration. Just go to the Web Server and verify settings of Management Service

 

image

Figure 2: You should configure Management Service to use Windows Authentication

image

Figure 3: You should be sure that Windows Credentials is enabled.

This is usually not enough, you should also be sure to add a value in the registry, you should locate HKLM\SOFTWARE\Microsoft\WebManagement\Server key and then add a DWORD value named WindowsAuthenticationEnabled with the value 1. Finally you should restart management service (net stop wmsvc and then net start wmsvc).

If you run the build you will probably still get the ERROR_USER_UNAUTHORIZED error, this is caused by parameters passed to MsBuild. There are two parameters you need to pass to MSBuild to have integrated security works and they are:

1) /p:UserName=””

2) /p:AuthType=NTLM

An empty username parameter is needed for it to work, if you forget to specify it, you will get ERROR_USER_UNAUTHORIZED even if the user running the script (tfsbuild) has all the right to deploy the site. The AuthType parameter is telling to the server to use Windows Authentication.

Now your build should be green and you have no credential stored inside the build definition and your are not breaking any security good practice.

Gian Maria.

News in TFS 2013 Build System

Team Foundation Server 2013 is finally RTM and it is time to explore some of its new functionalities and see what is changed between previous version. In the Build Area there are a lots of improvements especially because we now have Git Support and TFS presents a unified build experience between standard TFVC and Git.

Build workflow was redesigned and it got simplified, giving to the user an easier build authoring experience. In the extension area we now have the ability to specify scripts to be run before and after the build and before and after test are run. This give a really good extension experience, because it does not require you to do a workflow customization if you need to simply run some custom code during the build. This capability is especially useful when paired with Powershell.

Another really interesting modification is the location of the Build Workflows. All workflows are now contained into the server and not in Source Control. No more Build Process Template folder and confusion between different versions you have when you create Team Project after template are upgraded. When you need to customize the build, you can download a copy of the workflow and check-in in your source control.

You can now drop the build output directly into TFS avoiding the use of a network share if you prefer.

I suggest you to go to MSDN and grab the bits to experiment your own on this new capabilities.

Gian Maria.

Installing a Build controller against an Hosted TFS on Azure

One of the greatest news of yesterday was the availability of the TEam Foundation Server on Windows Azure. I can assure you that there is a huge hunting for invitation code (mine 5 are terminated after few minutes 😉 ) and this demonstrates the high interest that people have against TFS on Azure.

Clearly the other interesting news is the availability of the Developer Preview for the next version of Visual Studio (you can read the details here). In Jason Zander’s post there are no details for TFS, because a lot of details were already discussed in Brian Harry’s blog, but I assure that there are a lot of news for the new TFS version.

Finally I want to point out this video of Brian Keller on Channel9 that explain how to setup a build controller against your TfsPreview instance, so you are able to create build against project hosted on TfsPreview.

Have Fun.

Gian Maria.

Community extensions for TFS 2010 build

I’m happy to announce that on 4 of July 2010 the community TFS Build extensions project on codeplex published its first stable release.

TFS 2010 build system is based on Workflow Foundation and this means that you can extend writing custom activities (I blogged quite a lot about TFS Build in the past) or using legacy MSBuild actions. With this release you have now 100 new Actions / Activities you can use in your builds as well as a big amount of source code to understand how you can write extensions for Tfs Build System.

I strongly suggest you to have a look at it.

Alk.

Tags:

Getting code coverage result in drop folder during a TFS2010 buils

In a very old post I explained how to enable code coverage in TFS2010 builds and today I received a mail asking an interesting question.

The question is: “Is it possible to have Code Coverage result to be included in drop folder?”.

Answering this question is a two phase process, the first one is understanding where MsTest store results of code coverage and verify that is possible to do something useful with them. The answer is simple, you can simply look at the TestResult directory after you execute tests inside visual studio, and you will find a data.coverage file.

image

Figure 1: Test results does contains data.coverage file

If you open the file you find that this is a binary file, so it is really useful to have it copied on the Drop Folder? The answer is yes, because if you read this post, you will learn how to transform it into a XML file that can be human readable. You will find even some detail here, on how to create a stylesheet that convert the XML in something more readable, another Xsl stylesheet can be found here.

I must admit that I never tried those solutions, but the conclusion is: from a .coverage file is possible to extract useful data outside Visual Studio.

Now we should solve the other problem: how to have this data available on the drop folder after a TFS2010 Build is completed. A really quick and dirty way is to edit the workflow used in the build to copy the entire test result folder in the Drop Folder.

image

Figure 2: Copy all test results folder in drop location.

This modification simply copy the whole TestResults directory, from the folder where the build occours (variable TestResultDirectory) to the drop folder directory (BuildDetail.DropLocation variable).

image

Figure 3: Test results gets copied into the drop folder.

As you can verify, after a build, the entire TestResults folder is copied to the drop folder, so you can anlyze code coverage result with the tool you prefer.

This is a simply and dirty way to copy everything related to test result to the drop folder, you can issue a more intelligent command (even a xcopy.exe) that copy only the data.coverage if you are only interested in that file.

alk.