Changing TFS emails to link to Team System Web Access – Part 2 - Visual Studio Team System (VSTS) Blog - by Neno Loje

Neno Loje stated in Changing TFS emails to link to Team System Web Access – Part 2 - Visual Studio Team System (VSTS) Blog - by Neno Loje that:

"There are four areas to look at:
Work Item notification mails (has already been discussed here)
Build notification mails
Check-in notification mails
Mails sent by Team Explorer (feature of TFS 2008 SP1)
Area 1 is part of a separate blog post, for Area 2 there are currently no equivalent steps (as stated in KB956761)."

I just couldn't live with it so I made it work, like this in BuildCompletionEvent2.xsl:

   1:        <div class="Title">

   2:          <xsl:call-template name="link">

   3:            <xsl:with-param name="format" select="'html'"/>

   4:            <xsl:with-param name="embolden" select="'true'"/>

   5:            <xsl:with-param name="fontSize" select="'larger'"/>

   6:            <xsl:with-param name="link" select="concat(substring-before(Url,':8080/Build/Build.aspx?artifactMonike'),':8090/UI/Pages/Build/Details.aspx?builduri=vstfs%3A%2F%2F%2FBuild%2FBuild%2F',substring-after(Url,'artifactMoniker='))"/>

   7:            <xsl:with-param name="displayText" select="Title"/>

   8:          </xsl:call-template>

   9:        </div>

Where the point of the matter is line 11. The change was inspired by the original post by Neno and a simple fix.

To add even more we even changed it a bit more to include a link to a report over the failing tests for the last 72 hours. I am not showing the report part, but the take-away is the inclusion of the link:

 

   1:  <xsl:if test="StatusCode != 'Succeeded'">

   2:     <tr>

   3:       <td class="PropName">Build Log Location: </td>

   4:       <td class="PropValue">

   5:         <xsl:call-template name="link">

   6:           <xsl:with-param name="format" select="'html'"/>

   7:           <xsl:with-param name="embolden" select="'false'"/>

   8:           <xsl:with-param name="link" select="LogLocation"/>

   9:           <xsl:with-param name="displayText" select="LogLocation"/>

  10:         </xsl:call-template>

  11:       </td>

  12:     </tr>

  13:     <tr>

  14:       <xsl:call-template name="link">

  15:         <xsl:with-param name="format" select="'html'"/>

  16:         <xsl:with-param name="embolden" select="'true'"/>

  17:         <xsl:with-param name="fontSize" select="'larger'"/>

  18:         <xsl:with-param name="link" select="concat(substring-before(Url,':8080/Build/Build.aspx?artifactMonike'),'/ReportServer/Pages/ReportViewer.aspx?/Confirmit/Failed+Tests&rs%3aCommand=Render&BuildParam=',substring-after(Url,'artifactMoniker='))"/>

  19:         <xsl:with-param name="displayText" select="'Report on failing tests in this build'"/>

  20:       </xsl:call-template>

  21:     </tr>

  22:   </xsl:if>

The added code is the lines 13 – 21.

Happy coding

AdditionalReferencePaths can/will screw up your Team Build

Just spent several days pondering over a Team Build that only builds the first time after a thorough clean of the build directory. Prelimenary conclusion is as follows:

It seems like the AdditionalReferencePaths option is given a higher priority than the framework itself. This leads to resolving things like System.dll from the output path instead of from the relevant target framework(!!).

The reason I started thinking this is that the it was obvious from the build log that our output path was beeing preferred for stuff like System.dll, System.Data.dll etc. We are deliberately not using CopyLocal and simultaneously have set all our $(Output) to one directory. All file references are picked up from this folder.

I tested out this conclusion by simply removing the one AdditionalReferencePaths inclusion we had and it did the trick.

Now, this preference of AdditionalReferencePaths over target framework path cannot be a good descicion from MS can it?