ARB Security Solutions

TeamBuild – Error – Failure: unknown user name or bad password

adam — Mon, 08 Feb 2010 15:08:54 +0000

This particular error can be a pain in the ass to track down, and it will cause Team Build to be unable to create the drop directory. But there are only really two causes for it.

1) You will generally start seeing this error after a problem occurs with a build machine that causes you to recreate the drop location (meaning, it’s the only time I have seen it). Or something dealing with you remaking the drop location.
2) It can also come up with cross-domain development environments.

If you think you are experiencing problem #1
1) check whether the same same build agent for all the builds
2) check whether instead of an alias to refer to the machine you can use the IP

If you think you are experiencing problem #2

1) 9 times out of 10 this is a domain trust problem. Simply put, a TFS user domain doesn’t trust the TFSService account, thus when users are added the TFSService account doesn’t have the read permission on the domain controller. So you can either implement the domain trust or change the TFSService account to use the other domain.

Including Code Coverage Results In TFS Alerts

adam — Fri, 05 Feb 2010 18:58:00 +0000

Notifications are a fundamental component of a successful SharePoint continuous integration strategy approach. Maintaining continuous feedback on SharePoint products is an important counterpart of continuous integration for realizing agile SharePoint development. Without timely notifications about the status of a build, mostly broken builds, bottle necks can occur which negate the benefits of a SharePoint CI implementation.

While doing a TFS 2008 upgrade that was heavily used for SharePoint development I was recently doing for a financial institution customizing these emails came up to adapt to the organizations CI policy. Specifically, how one could include the code coverage results in the email.

Under normal circumstances TFS provides a pretty reasonable mechanism to achieve notifications for CI. Individual email alerts are structured around an XSL template found in the TFS server installation directory then under Web Services -> Services -> v1.0 -> Transforms. Adjusting the XSL will change things like the text that the user receives. It is important to note that these files, like most hived files in SharePoint, are mutable with service packs and changing them can mean that future installers will not pick up the files due to the adjusted timestamp. Thus, it is typical to make a backup of the file to restore when applying updates, then rolling in the custom changes that were made previously into the updated files.

Now for the disappointing news. After scouring the completion event schemas for builds there is no field that provides the code coverage metrics, thus it makes it really hard if one wants to include code coverage data. Without this, you can’t not only not add it to the email, but to the Build webform. As a really poor substitute you can get the code coverage data from TSWA though, and you could point the email to look at the code coverage data through that medium. I think it’s a pretty lame solution.

An ACTUAL Fix For TFS SSRS Error Query Execution Failed For Data Set

adam — Wed, 03 Feb 2010 17:33:14 +0000

After doing a TFS migration between 2005 – 2008/2010, you may notice that there is a problem with your SSRS displaying reports. Most frequently this will occur when a service pack is applied. While some, such as the Velocity report, just won’t display data, others like those dealing with bugs will lead to the following SSRS error being reported:

An error has occurred during report processing. (rsProcessingAborted)
Query execution failed for data set ‘PriorityParam’. (rsErrorExecutingCommand)
Query (19, 2) The ALLMEMBERS function expects a hierarchy expression for the argument. A member expression was used.

The data set parameter in the exception return will vary depending on the report you are doing, but it is a consistent error regardless.
Now at first glance, this is post migration / potentially post service pack, so it would lead one to believe that for some reason the .rdl files didn’t get updated to the new version. Since I didn’t have a ton of projects I unpackaged them out of the fitting.stp files, and tried manually uploading them in the Report Manager. This had no effect.
After Googling my butt off, trying all these ambiguous fixes, and trying to rebuild the TFS warehouse with 50,000 different permutations on the available switches, I sat down and found the fix myself.

Where this problem crops up is for some reason the TBL_Database table in the TfsIntegration database has a remote server, a.k.a your source TFS server for migration, name for SSAS. Now why the hell is this? Well, it’s because the MSIProperty.ini file has an entry for the same remote SSAS instance and this can be picked up and employed by service packs and other updates. When the warehouse controller starts the adapters, the process attempt to hit the remote server, which will causes the reports to fail. Once you change the SSAS server value in MSIProperty.ini and the server parameter inside TBL_Database of the TFSIntegration table, the warehouse controller will be able to run the adapters successfully.
Once the adapters are run the reports will start showing up successfully.

IAG Custom Endpoint Application Detection – Structure

adam — Mon, 01 Feb 2010 18:38:19 +0000

When you are writing custom endpoint detection scripts, I found the documentation regarding the use of different values very, very confusing. So here is a breakdown of em after reflecting on how UAG uses them.

Name: This represents the name of the variable, since you add the required XML file to the customupdate folder and that represents your custom variable.
ID: The results variable you are using to record the return.
Type : the TYPE of endpoint detection your adding, but it gets tricky because it can either be something specific or an expression. Like you can just check for a certain IE version or bundle up the check with other stuff into an expression.
Value: the default value you want to use to make endpoint detection fail.
Description: A description of the variable.
Section – section to display in the interface.
Flags – This is kinda funny because this is actually because the product was acquired by Whale, they used the flags variable to detect things like host file inclusions.

That’s all of em.

Quick Tip: Use Simple Trunks External SharePoint IAG HAT

adam — Mon, 01 Feb 2010 18:08:44 +0000

If you don’t want your public facing SharePoint sites in environments to be subject to public HAT & address rewriting, remember that you have to enable a Basic trunk. This can be done by creating a new trunk under HTTP and selecting the “basic trunk” option. If truly public, it is also best to disable the installation of endpoint components and toggle any authentication stuff.

Executing (Multiple) Target Injection in TFS

adam — Mon, 01 Feb 2010 17:33:14 +0000

It seems I am never going to be rid of finishing these automating events! One problem that we tackled today dealt with TFS target injection, where you want to call other targets at different points in the build process. An example of this is when you want to wire a target before/after something like SolutionToBuild and ConfigurationToBuild, perhaps to do a little work before the build starts. In this case, the build was chained to **another** build to do a get on a separate VC instance, and build a related solution beforehand. There was also some WIT stuff to be done too.

Fortunately, TFS Build makes this pretty easy through the use of the Before* or After* targets (which are easily grafted from Microsoft.TeamFoundation.Build.targets), most you will ever need are existing but if you need a different one you can use a CallTarget with a MSBuild task. This can get even cooler, because you can actually start to build chained dependencies through something like:

PLAIN TEXT

XML:

Name="BeforeCompile" DependsOnTargets="CustomTarget" />

Pretty neat!

Considerations When Using TFS for SharePoint And Silverlight Development

adam — Mon, 01 Feb 2010 16:23:05 +0000

During testing of my recent TFS migration we found a small issue with a SharePoint Application Page build that had some embedded Silverlight in it where the ClientBin directory was not being created by TeamBuild.

The error looks similar to the following:

MSBuild\Microsoft\VisualStudio\v9.0\WebApplications\Microsoft.WebApplication.targets(60,3): error MSB3021: Unable to copy file "ClientBin\Base.Silverlight..xap" to "\". Could not find a part of the path 'ClientBin\.xap'.

So why does this happen? There could be a couple reasons you might be running into this particular error, the largest of which is the default settings of TFS not checking in the XAP files. Which doesn't make a ton of sense. Also, you will generally run into this error when a Siliverlight project is renamed and its parent directory is renamed. Which of these causing the error will determine the appropriate resolution path.

If you are running into this because you think you are hitting the renaming error, then the easiest way to fix it is to unload the project, edit .csproj, and correct the values in the tag. After you perform a check-in and start a build the error will go away. If you are not entirely sure why it is happening and the aforementioned renaming doesn't sound like your issue, then you can implement a couple of other things to get around the problem.

Firstly, change the referring Content item in the xap file:

PLAIN TEXT

XML:

Include="ClientBin\.xap" Condition="$(IsDesktopBuild) == true" />
XAP NAME>.xap" Condition="$(IsDesktopBuild) != true" />

Following, in the AfterDropBuild Target, execute a manual copy of the xap to the _PublishedWebsites folder:

PLAIN TEXT

XML:

Command="xcopy /y "$(MSBuildProjectDirectory)\\Debug\Base.Silverlight. .xap" "$(MSBuildProjectDirectory)\\Debug\_PublishedWebsites\Base\ClientBin"" />

After, you should be good to go!

Using A Junction Point Drop Strategy In SharePoint Development

adam — Fri, 29 Jan 2010 16:21:00 +0000

It's my last day of my TFS migration, which I will admit I am pretty happy about being complete with. Everything goes into testing for the next couple weeks, so it's time to sit back and see what people can break.

An interesting point came up today on the second to last project we were converting for build automation. One of the solutions composed of multiple projects employs a separate third party pickup program for deployment of its respective packages, and because of its nature this scheme is not mutable. Off the cuff, this is obviously a no brainer to configure the build drops, but the requirement became slightly more complex. This particular program required a junction point drop, so when a solution structured with multiple projects is assembled it would output project contents under $(BinariesRoot)\project ($(BinariesRoot) being where TFS Build wants to place your binaries during a build, TFS Build sets $(OutDir) to $(BinariesRoot)), as opposed to restricted to the default solution structure. This could be for any number of projects within the solution, $(BinariesRoot)\projectX, $(BinariesRoot)\projectY, $(BinariesRoot)\projectZ, etc.

The solution to this is to use $(CustomizableOutDir) (false by default!) which will use the project settings instead of being overridden by TFS Build. So in each .csproj file you would have:

PLAIN TEXT

XML:

Condition=" '$(IsDesktopBuild)' == 'false' ">$(BinariesRoot)\projectX>

Viola!

Chaining SharePoint Builds Status

adam — Wed, 27 Jan 2010 19:01:52 +0000

So I am still in migration hell and fixing some build code. One of the problems we just ran into was chaining build events. Consider if you had SharePoint project X which contained and Exec command that triggered SharePoint project Y. The goal of their custom build is to query into the build status of SharePoint project Y, and display the build status in SharePoint project X's build status. Put simply, I needed a mechanism where Project Y build status, like whether it returns Success, Partial Success, etc.

Fortunately, this isn't terribly difficult using the Exec task to execute a command leveraging the exitcode to get the status. This looks like the following:

PLAIN TEXT

XML:

Name="MyBuildTarget">
Command="tfsbuild start /server:myserver /builddefinition:\mytfsproject\buildprojectb" ContinueOnError="true">
TaskParameter="ExitCode" PropertyName="BuildProjectExitCode"/>
>
Text="BuildProjectExitCode=$(BuildProjectExitCode)">>
>

The exitcode return will be an integer, which is easy to correlate to the respective return values, Failure is 100, Partial Success is 1, Success is 0, Unknown is -1, and Unrecognized Command is 2.

Creating TFS Work items Based On SharePoint Build Outcome

adam — Wed, 27 Jan 2010 15:29:19 +0000

While fixing builds for my current project, and I'm now finally about half way through em, one problem that bubbled up was that the previously employed build manager had attempted to put together some code to have a build based on compilation success/failure of his SharePoint projects to generate work items. Now, at first glance his code looked correct to me (I've stripped it down a stitch):

PLAIN TEXT

XML:

TaskName="Microsoft.TeamFounadtion.Build.Tasks.CreateNewWorkItem" AssemblyFile="$(TeamBuildRefPath)\Microsoft.TeamFoundation.Build.Tasks.VersionControl.dll" />
Name="AfterCompile" Condition=" '$(BuildBreak)'!='true' and '$(IsDesktopBuild)'!='true' ">
TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
BuildId="$(BuildNumber)"
Description="BUILDLOG : $(DropLocation)$(BuildNumber)\BuildLog.txt."
TeamProject="$(TeamProject)"
Title="Build - $(BuildNumber) completed just great!"
WorkItemFieldValues="$(WorkItemFieldValues)"
WorkItemType="$(WorkItemType)"
ContinueOnError="true"
/>
>

Nothing about that at first glance looked wrong, but he was getting the error:

A Work Item could not be created for failures in build 'build'. Please verify that the work item type 'Task' is supported in team project 'proj' and it has field 'Microsoft.VSTS.Build.FoundIn' defined.

Now this problem implies that there wasn't some of the required foundation laid down before the aforementioned code was integrated. Basically, a work item type Task defined in your team project, then you need to create that first. So bascially hack up the work item type definition file with those definitions, and you are good to go!

ARB Security Solutions

TeamBuild – Error – Failure: unknown user name or bad password

Related posts

Including Code Coverage Results In TFS Alerts

Related posts

An ACTUAL Fix For TFS SSRS Error Query Execution Failed For Data Set

Related posts

IAG Custom Endpoint Application Detection – Structure

Related posts

Quick Tip: Use Simple Trunks External SharePoint IAG HAT

Related posts

Executing (Multiple) Target Injection in TFS

Related posts

Considerations When Using TFS for SharePoint And Silverlight Development

Related posts

Using A Junction Point Drop Strategy In SharePoint Development

Related posts

Chaining SharePoint Builds Status

Related posts

Creating TFS Work items Based On SharePoint Build Outcome

Related posts