BM-Bloggers

The blogs of Black Marble staff

MSB3155 errors in Team build when publishing to click once

If your team build project uses the Publish Target option (to create a ClickOnce deploy) you may see the error

BuildWallboard.csproj" (Publish target) (3:5) ->
(_DeploymentGenerateBootstrapper target) ->
MSB3155: Item 'Microsoft.Net.Framework.3.5.SP1' could not be located in BuildWallboard'.
MSB3155: Item 'Microsoft.Windows.Installer.3.1' could not be located in BuildWallboard'.

This is because on the build server needs a ‘default installation’ of Visual Studio Developer (or Suite). The publish function, like the MSTest function is not something the Team Build server can do bit itself it needs Visual Studio to do the heavy lifting.

Should my TFS Build Server be 32bit or 64bit?

I would say at this time unless you need 64Bit specific assemblies built you are best staying on a 32bit operating system. This will happily build MSIL .NET assemblies which I guess for most of us is the bulk of our work. OK you loose a bit of performance if you have 64bit hardware (or virtual hardware in our case), but I doubt this will be critical, shaving a few seconds of an automated build is not normally important.

My main reason for saying this is what as you extend your build process you will no doubt started to use community developed build activities, some of these seem to get a bit confused if you are on a 64bit OS. The issue seems to be that they cannot easily find the TFS Client assemblies in C:\Program File (x86) as opposed to C:\Program File. For example we have a build that automatically updates version numbers and deploys via ClickOnce; it works fine on a 32bit W2k8 build server, but on an identically configured 64bt W2K8 build server it gives the error:

error MSB4018: The "MSBuild.Community.Tasks.Tfs.TfsVersion" task failed unexpectedly.
error MSB4018: System.IO.FileNotFoundException: Could not load file or assembly 'file:///C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies\Microsoft.TeamFoundation.Client.dll' or one of its dependencies. The system cannot find the file specified.

So what appears to be just a simple path issue, that is probably fixable in an XML configuration file or with search paths – but is it worth the effort? I would say not in general. I want to keep my installation as near default as possible, which I can with 32bit.

Getting MSB6006 errors for MSTest under TFS Team Build 2008

I have been rebuilding our TFS build systems on Hyper-V based virtualised hardware. The long term plan being to hold a configured build server as as Hyper-V template to we could prevision extra ones quickly, or rebuild all of them if we need to upgrade some library or tool; in effect to give us revision control over our build servers.

All seemed to be going OK, initially existing builds seemed to be running OK when targeted at the new server. However I soon saw that tests were failing with the error

MSBUILD : warning MSB6006: "MSTest.exe" exited with code 1

Further digging into the build log showed the tests were being run but the copy to the drop location was failing.

Side note: if you read older TFS documentations and many blogs it says to add the flag

/v:diagnostic

to the TFSbuild.rsp file to get more logging – this is wrong with MSBuild 3.5 as used by TFS 2008. This now defaults to the highest level of logging, so to reduced it you must use

/fileLoggerParameters:verbosity=normal

so no help in debugging. Anyway back to the plot……

In the past our single build server used a share on its own disk as the file drop, but now as we intend multiple build servers I decided to have a central build share on main data store server. This had been setup with read/write access to the folder and the share associated for the tfsbuild domain user that the Team Build service runs as.

Turns out this is not enough. You also have to give read/write access to the tfsservice domain user as well. It seems the publish of the test results comes from the TFS server  not the build process. hence needing the extra rights. Once the change is made all work fine

TFS TeamBuild and Sharepoint WSP deployment (and any post build events for that matter)

We use the SharePoint Visual Studio Project Template on CodePlex to create WSP deployment packages for our SharePoint features. I tend to think of this WSP creation project in the same way as a MSI installer; so we don’t put SharePoint components into the WSP solution itself, it is an extra project in the solution that assembles the components from a variety of other solutions (e.g. web parts, workflows, event receivers, shared libraries for the GAC etc) and builds a single deployable WSP file.

Running locally on a developers PC inside Visual Studio this template has worked well, the only change I make from the default is to alter the WSP projects pre-build event script to xcopy all the files into the correct directories to allow the VBScript files to create the WSP.

In our drive to automation and automatic testing I have been looking at getting the WSP created as part of our TFS Team Build process. It turns out you get a few problems because Visual Studio and Team Build do macro expansion differently.

So my Pre-build event becomes

echo PREBUILD STARTED

rem Check if we running in VS or Teambuild
if not exist "..\..\..\CLIENTLIBRARY\SharedLibProject\bin\$(ConfigurationName)\SharedLibProject.dll" goto tfsbuild

echo Copy from VS locations, in this sample we assume a shared library, a webpart and some javascript
xcopy "..\..\..\CLIENTLIBRARY\SharedLibProject\bin\$(ConfigurationName)\SharedLibProject.dll"  "$(ProjectDir)DLLS\GAC\"  /F /R /Y
xcopy "..\..\..\Web Part\bin\$(ConfigurationName)\*.dll"  "$(ProjectDir)DLLS\GAC\"  /F /R /Y
xcopy "$(SolutionDir)HOST\bin\HOST.dll"  "$(ProjectDir)DLLS\GAC\"  /F /R /Y
xcopy "$(SolutionDir)HOST\json*"  "$(ProjectDir)TEMPLATE\LAYOUTS"  /F /R /Y
xcopy "$(SolutionDir)HOST\*.js"  "$(ProjectDir)TEMPLATE\LAYOUTS"  /F /R /Y

goto end

:tfsbuild
echo Copy from TFS build locations

xcopy "$(outdir)\SharedLibproject.dll"  "$(ProjectDir)DLLS\GAC\"  /F /R /Y

xcopy "$(outdir)\WebPart.Core.dll"  "$(ProjectDir)DLLS\GAC\"   /F /R /Y
xcopy "$(outdir)\WebPart.UI.dll"  "$(ProjectDir)DLLS\GAC\"   /F /R /Y
xcopy "$(outdir)\Host.dll"  "$(ProjectDir)DLLS\GAC\"   /F /R /Y
xcopy "$(SolutionDir)HOST\json*"  "$(ProjectDir)TEMPLATE\LAYOUTS\json*"  /F /R /Y
xcopy "$(SolutionDir)HOST\*.js"  "$(ProjectDir)TEMPLATE\LAYOUTS\*.js"   /F /R /Y

:end

echo PREBUILD COMPLETE

Key points to note here are

  • For Visual Studio you can use Xcopy /s it makes no difference as there are no sub-directories (so you might ask why use it it all, I guess in some cases a generic copy all is easier than specifying a fixed file and directory). This is not the case for Team Build, if you use /s you can get multiple copies of DLLs in sub-directories created. This is because of the way Team Build structures it’s directories. The $(outdir)  is not a subdirectory of the $(solutiondir) as it is in Visual Studio, it is an absolute path defined for the build agents settings where all the outputs for all the projects in the build are assembled. So, depending on the project type, you seem to get sub directories. So it is best to be very specific as to what to copy, avoid wildcards and recursion.
  • When doing a wildcard xcopy as with json* files on Team Build you must specify the copy to file name i.e. json*, if you don’t you get the question ‘is the target a file or a directory’ message which obviously kills the build. This does not occur within Visual Studio.

It is also worth altering the post build event, by default the WSP is created in the project root, but if it is copied to the $(outdir) it ends up in the Team build drop location, so can be picked up by anyone, just like a DLL.

echo POSTBUILD STARTED
rem commented out as the build box does not have SharePoint installed
rem this could be wrappered in the chheck to see if the directory is present if we are on tema build or not
rem XCOPY "$(ProjectDir)TEMPLATE\*" "C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE" /S /F /R /Y

echo Run the VBscripts to create the XML files
"$(ProjectDir)CreateManifest.vbs" "$(ProjectDir)" "$(ProjectName)"
"$(ProjectDir)CreateCabDDF.vbs" "$(ProjectDir)" "$(ProjectName)"

echo Build the WSP
cd "$(ProjectDir)"
makecab.exe /F cab.ddf

echo Copy it to the out directory
xcopy *.wsp "$(TargetDir)\*.wsp" /y

echo POSTBUILD COMPLETE

However your problems do not end here. If you build this WSP project locally on a development PC all is fine. However (depending upon you project) it may fail on Team Build, well actually not fail just pause forever. This due to the way that Team Build checks out folders. The WSP project has a folder structure you drop files in that the VBScript files scan to create the manifest and then the WSP. If one of these directories is empty then it is not created on the build box and the VBScript stalls.

The solution is simply just add an extra folder exists check in the CreateCabDDF.vbs file’s EnumFolder method

sub EnumFolder(sFolder, sRelativePath)
    dim oFolder, oFolders, oSub, oFile
    
    rem this is the extra line
    If oFS.FolderExists(sFolder) Then

        set oFolder = oFS.GetFolder(sFolder)
    
        if (sRelativePath = "TEMPLATE") then sRelativePath = ""
        if (sRelativePath = "FEATURES") then sRelativePath = ""
    
        if (sRelativePath <> "") then sRelativePath = sRelativePath + "\"
    
        for each oFile in oFolder.Files
            oDDF.WriteLine """" + oFile.Path + """" + vbTab + """" + sRelativePath + oFile.Name + """"
        next

        if (sRelativePath <> "" and InStr(1, sFolder, "FEATURES") > 0) then
            sRelativePath = "FEATURES\" + sRelativePath
        end if

       for each oSub in oFolder.SubFolders
            EnumFolder oSub.Path, sRelativePath + oSub.Name
       next
    
      end if
    
end sub

Once this is all one the you can build the project in the Team Build

We Just Keep on Giving at Xmas …

Update – just needed to correct myself … it is a Kringle-O-Tron not a Robot Santa! D’oh!

In case you missed it … we are providing cut out and keep Santa and Kringle-O-Tron with our online Xmas cards this year.  They make up wonderful little models, with just folding and cutting!  As we can testify to by the number dotted around our offices.  Graphics Girl has done us proud.

Click on the picture for a bigger view … but visit the site to print them out next to ‘Cut Out and Fold Projects’.

foldsanta_robot

She has also provided the entire Senior Management Team at Black Marble with their own little models … if there is a demand, I can make these available too!

BizTalk 2009 and ESB 2.0

BizTalk 2009 CTP is now out along side ESB 2.0 CTP and RFID(Mobile)

BizTalk 2009 supports visual studio 2008 , SQL Server 2008 AND TFS with some great new tooling for development and application lifecycle management.

BizTalk RFID Mobile enhances BizTalk Server RFID by offering device management and offline processing capabilities using Windows CE based machines. BizTalk RFID Mobile is free to all BizTalk Server with Microsoft Software Assurance. With 2009 BizTalk RFID Mobile will be available as part of the  license.

The BizTalk 2009 CTP is available from Here.

The Enterprise Service Bus (ESB) Guidance 2.0 is available at Here.

b.

Christmas Cheer from Black Marble

xmas_01

Following the wonderfully successful Black Marble Brigade Xmas Card in 2007, we are back with a great set of designs this year too.  Graphics Girl has produced a wonderful ‘traditional’ card (above) that will have landed on your desk this year … as well as a selection of others that didn’t quite make the cut … we had such trouble selecting!  You can view them as they are published (every Monday and Thursday through December) online here.

xmas_04

December’s Guest Coke

At Black Marble we try to always go one step further, one of the popular things we do is to get international varieties of coke and other pop/soda from Korean to American.  This December, the Guest Cokes filling your fridge include the very exotic Irish variety of regular coke … and also a French Diet Coke!  Enjoy.

dietcoke

Steve Ballmer’s MVP Live Search Challenge

At the last MVP Summit Steve Ballmer said “I’m going to ask you one week switch your default [search engine], one week. At the end of the week…I’ll want feedback, how was your week, what happened, what did you like, what didn’t you like … Can I make that deal with you? (Cheers and applause.) That’s the deal.”

Well the week was last week, and how did I find Live Search?

I have to say it is vastly improved, in the past I just assumed Live Search would find nothing of use, especially if I was after something I would expect to find on a Microsoft site like TechNet.

This week I have found that though it does not return exactly the same a Google, it is just as useful; in fact the two are fairly complimentary. For most searches it does not now seem to matter which one I used, but when really digging one might turn up something the other does not.

So am I going to move back to Goggle? Well I am just not sure it matters for day to day searching. I certainly don’t now feel the need to change my default search engine to Google immediately when I setup a PC as I used to.

live