3

I'm having a very hard time finding any information about this. I've just created a Build-Deploy-Test build definition for one of our main projects but when the workflow runs, it reports a wrong value for the "$(BuildLocation)" macro, which breaks everything from the deployment phase onwards (the tests also try to run over this wrong path).

I know what is causing the problem, but I don't know how to fix it. The build definition we are redirecting the lab one to is configured to build the 'Release' configuration of our solutions. The drop folder is "\outputServer\drops". I expected the BuildLocation macro to then return "\\outputServer\drops\<BuildName>\<BuildNameFormat>", but the macro is returning "\\outputServer\drops\<BuildName>\<BuildNameFormat>\Release" instead.

I initially thought that this was an incompatibility between the LabDefaultTemplate.11.xaml template (which is the one I'm trying to use) and the old DefaultTemplate.xaml, which I based our custom template over. I tried updating our custom template to take the new default (DefaultTemplate.11.1.xaml) as a base, but after converting the template the problem persists.

Even after looking at the code on the DefaultTemplate.11.1, I still don't see it filter the output by configuration names at all. The only processing in there is based on the solution or project name, which is disabled by default (controlled by the 'Solution Specific Build Outputs' option under the Advanced category, on the build definition configuration).

Why is it assuming that the drop folder ends with 'Release' while the dropped outputs are not placed on this folder at all? I managed to make the deployment scripts to run fine by appending a ".." to the path, like this $(BuildLocation)\..\myScript but when the workflow tries to run the automated tests it seems to be using this same macro and obviously doesn't find the test dlls.

It would be possible to work around this by not specifying a build configuration on the 'Items to Build' element in the definition options (thus letting it choose the default ones), but specifying the configuration was a conscious decision on our part, because there are differences in the files and some configs are transformed differently when the project is built in Release mode.

I'm currently using VS2012 Update 3/TFS 2012 Update 2 it this helps any.

Update:

Ok I found where it is doing this inside the template itself. The fact that the lab workflow is very simple helped here.

Inside the Compute build location needed 'if statement', there is an assignment that seems to be doing this weird concatenation. Here is the code:

If(LabWorkflowParameters.BuildDetails.Configuration Is Nothing, BuildLocation, If(LabWorkflowParameters.BuildDetails.Configuration.IsEmpty Or (SelectedBuildDetail.Information.GetNodesByType(Microsoft.TeamFoundation.Build.Common.InformationTypes.ConfigurationSummary, True)).Count = 1, BuildLocation, If(LabWorkflowParameters.BuildDetails.Configuration.IsPlatformEmptyOrAnyCpu, BuildLocation + "\" + LabWorkflowParameters.BuildDetails.Configuration.Configuration, BuildLocation + "\" + LabWorkflowParameters.BuildDetails.Configuration.Platform + "\" + LabWorkflowParameters.BuildDetails.Configuration.Configuration)))

I'm not even sure what this is supposed to mean. This behavior seems to be a bug to me, since the build template itself (not the lab one) does NOT do this concatenation. How can the LabTemplate assume this type of thing?

julealgon
  • 7,072
  • 3
  • 32
  • 77
  • I've got the same problem. I also tried to remove the AnyCpu platform setting from the build config, but that doesn't work either. – jochen.vg Oct 15 '13 at 08:06

1 Answers1

2

Just removing the activity from the LabDefaultTemplate build process template seems to work.

I'm not sure what the meaning or purpose is of that Assign activity, but it seems to work fine for us without it.

Remove This Activtiy

jochen.vg
  • 302
  • 2
  • 7
  • Yes, I did something similar to temporarily work arount it: I modified the template and put a parameter to alternate between these "build output dependent paths" and what I assume would be more correct, to "not concatenate anything". – julealgon Oct 15 '13 at 15:21