WebDeployproblem – error message not obvious

We have been using WebDeploy along with Beta 2 of TFS for some while. We have a local IIS installed on the WebServer and the build is taking the settings from this IIS when preparing the deploy package.

Last week we installed the RC of Visual Studio and TFS. Instead of upgrading the Build server we installed a new one. Besides from the problem with Build Defintions that I blogged about we had one peculiar problem. We got an error when building that said:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets (1650): The “MapUriToIisWebServer” task failed unexpectedly.
When making a search on “MapUriToIisWebServer” I found one (!) reference – how often does that happen! It referenced to the Connect site and a bug report. This told me a workaround would be to uncheck “Apply server settings to all users” on the Web tab of the Project Properties. I made this change and now it worked. Satisfied with solving that I went on with next thing without giving much thought to this…

However, things started to become strange to another user, that settings were not preserved and so on. So we started looking at this a bit more and realized what the checkbox actually did, when uncechking some settings were removed from the project file and ended up in a personal setting instead – not what we wanted.

So we started digging into this. A local build in VS worked. So to track down the error I went to the build server trying to do the same build. And this is when things started to show up. Loading the web project that contained the webdeployment did not work. An error message similar to this appeared:

The components it complained about was the IIS 6 Management Compability and some more stuff related to IIS 6. So I ended up looking at Vishal Joshis blog post about Basic Microsoft Web Deployment Tool Setup For Visual Studio 2010 and ended up installing some role services. First I tried to add the things he highlights but ended up added everything with Security and everything with IIS 6 as well as the Management Service.  

Now I was certain it would work, but I ended up with another error that is pretty new and unfamiliar to a Windows XP user:

I checked, and the account I was running under was an administrator. Then I realized I was not running the process as administrator. So right-click and say “Run as administrator” made the trick. Now it works.

A long way to a pretty simple error, but the first indication of the error was not that obvious…

Advertisement

Solving build problems after upgrading from Beta2 to RC

If you like me did not read the upgrade manual thoroughly before trying to run your existing Beta2-builds in TFS 2010 RC you might have encountered some or all of these problems. (Upgrade manual can be found in this post http://blogs.msdn.com/bkrieger/archive/2010/02/03/tfs-2010-beta2-to-rc-upgrade-guide.aspx)

Build ends with the following error: File not found: C:\Windows\Microsoft.NET\Framework\v4.0.21006\MSBuild.exe
If you look in the Framework folder you notice that the RC of .NET Framework is in a folder called v4.0.30128 – so of course the files cannot be found.
In the upgrade guide, chapter 5 – point 3 you can read that you have to update your Build templates. It also says to create a new project and take the templates from there. One point that is not that clear in the guide is that if you create a new project in a Collection that was created under Beta2 you will get the Beta2 templates. So you will have to create a new Collection and then create a new project in that collection to be able to get a hold on the new Build templates. So the steps in chapter 5, point 2 is what you should do for the build templates as well.
I also made the obvious mistake not the check-in the new templates after adding them, so I did not find the new templates at first. Luckily I have made this error several times, so I knew how to solve it 😉

Since we installed a complete new Build Server with the RC version we ran into the following problem as well.
When using Lab Management you have several Agents. So when configuring your builds you might point to the Build Server as described in this post https://tomasscott.wordpress.com/2010/01/09/default-setting-might-cause-problems-with-tfs2010-builds/
Remember to change that value for the build server as well as the value on the tab Build Defaults.

Enjoy the RC!

User experience with Gated Check-in

When your TFS administrator has enabled the Gated Check-in feature you do not notice anything at first. However, when you check in files a new dialog box appears:

As you can see in the green-marked area the system has created a Shelveset where your changes are stored temporary. The changes are then being built using the build server. If the build is successful the changes are committed, otherwise they are not – which means your changes have not been checked-in.

The red-marked area shows a check-box that makes it possible to choose if your changes should be kept locally or not. Default is that they are preserved (as in the picture). More about this later.

In the Build Explorer a build that is triggered via a Gated Check-in is indicated by an icon showing up next to the build, see this image:

Above the green indicator (that I put there) you can see the icon. In the same place you see the clock icon if it is a scheduled build and so on.

When the build has been finished it either when all green and the check-in has committed, or an unsuccessful build was the result, and then the check-in was Rejected. As a user you notice this as a pop-up dialog is diaplayed. Below you can see the two different dialogs:

In the case where the Check-in has committed you probably want to make sure your workspace looks the same as what has been checked-in. You do this by pressing the Reconcile button. If you checked the “Preserve my pending changes locally” you the tool will sync everything for you. You can find the same functionality in the Build Explorer if you bring up the build log. There you can see if the check-in was Committed or Rejected and you can perform the Reconcilation from there as well.

Some important point to think about:
– Your changes are not Check-in if the build was not successful. A partially successful build is considered unsuccessful.
– If the build works locally, but not at check-in, one thing to look for is project reference problems

This feature will most certainly change the work behavior of the users. Make sure not to get any strange mis-behavior…

Good luck!

Configuring Gated Check-In

You have probably heard of a new feature in Visual Studio/TFS 2010 called Gated Check-In. The problem this is supposed to solve is the problem of broken builds – when a check-in makes the next build fail. In order to start using this feature you configure it in a certain way.

First you create a Build definition pointing out the solution you want to build in your “Gate”. You configure it to trigger at Gated Check-in as below.

Next important step is to chose when this build should trigger. This is configured under the Workspace tab in the Build definition. By pointing out a workspace location, whenever trying to check-in a file to that workspace a new build is triggered. In our current application we have three different solutions and each has its own build associated to it.

The functionality you get will make it impossible to check-in anything whenever this build is unsuccessful. Remember that a partially successful build, for example when some unit tests fail, will be considered an unsuccessful build.

I have also posted about the user experience Gated Check-in, se this post https://tomasscott.wordpress.com/2010/02/07/user-experience-with-gated-check-in/