There is a call for speaker for DDD in Dublin on the 9th of October, that is not that far away is it!
Test Professional, after the Lab Management update, now uses Expression Encoder 4.0 to create it video of screen activity. This means that when you run a test and record a video you end up with an attachment called ScreenCapture.xesc.
Now my PC did not have the Expression Encoder 4.0 installed, so did not know what to do with an .xesc file created within our Lab Management environment. To address this the answer is simple. On any PC that might want to view the video either:
Once either of these is done, Media Player can play the .xesc file.
Interesting user too stupid error today whist adding some CodeUI tests to a Lab Management deployment scenario.
I added the Test Case and associated it with Coded UI test in Visual Studio
I made sure my deployment build had the tests selected
I then ran my Lab Deployment build, but got the error
Build directory of the test run is not specified or does not exist.
This normally means the test VM cannot see the share containing the build. I checked the agent login on the test VM could view the drop location, that was OK, but when I looked for the assembly containing my coded UI tests was just not there.
Then I remembered……..
The Lab build can take loads of snapshots and do a sub-build of the actual product. This all very good for production scenarios, but when you are learning about Lab Management or debugging scripts it can be really slow. To speed up the process I had told my Deploy build to not take snapshots and the use the last compile/build drop it could find. I had just forgotten to rebuild my application on the build server after I had added the coded UI tests. So I rebuild that and tried again, but I got the same problem.
It turns out that though I was missing the assembly the error was before it was required. The true real error was not who the various agents were running as, but the account the test controller was running as. The key was to check the test run log. This can be accessed from the Test Run results (I seemed to have a blind spot looking for these result)
This showed problem, I had selected the default ‘Network Service’ account for the test controller and had not granted it rights to the drop location.
I changed the account to my tfs210lab account as used by the agents and all was OK.
I have been using the ExternalTestRunner 2010 Build activity I wrote. I realised that at least one of the parameters I need to set, the ProjectCollection used to publish the test results, was hard coded in my sample. It was set in the form
This is not that sensible, as this value is available using the build API as
It makes no sense to hard code the name of the server if the build system already knows it.
This simple change means that the build templates can be fair easier past between Team Projects Collections
Access MVP Ben Clothier has posted an article and video on Going beyond Web Macros: Using Event Receivers & .NET with Access Services. This takes some of the techniques I was proposing for .NET/Access integration and added to them using Ben’s extensive experience in the Access space.
Well worth a look if you want to make Access a RAD front end to legacy systems.
Just spent a while battling a problem whilst install the TFS 2010 Test Controller. When I launched the install setup program off the .ISO I could select the Test Controller installer, but then a command prompt flashed up and exited with no obvious error. If I went into the TestControllers directory on the mounted .ISO and ran the setup from a command prompt I saw the error "program too big to fit in memory".
As the box I was trying to use only had 1Gb of memory (below the recommended minimum), I upped it to 2Gb and then to 4Gb but still got the same error.
Turns out the problem was a corrupt .ISO once I had downloaded it again, and dropped by target VM to 2Gb of memory all was fine.
I am very impressed with the iPlayer Media Center Plugin I found on the Australian Media Center Community, I like most people found it installed fine but that it failed to add itself to the start menu. However this was easily fixed using Media Center Studio once I got my head around the Media Center Studio’s user interface. The basic process is:
- Load Media Center Studio
- Go onto the Start Menu tab
- At the bottom of the screen look for the entry points section (needs expanding usually)
- In here you should find the iPlayer application (has a red’ish pay button logo)
- Drag it onto whichever part of the start menu you want, but be aware there are some limitation as to where it can go, Extensions worked fine for me
- Save the changes
- Restart Media Center
Once this is done you should be able to view WMV based iPlayer content from within Media Center. I have seen it take a while to start buffering content, but other than that it seems to work well and certainly looks the part.
Another follow up post, this time to the one on MSDeploy. As I said in that post a better way to trigger the MSDeploy PowerShell script would be as part of the build workflow, as opposed to a post build action in the MSBuild phase. Doing it this way means if the build failed testing, after MSBuild complete, you can still choose not to run MSDeploy.
I have implemented this using an InvokeProcess call in my build workflow, which I have placed just before Gated checking logic at the end of the process template.
The if statement is there so I only deploy if a deploy location is set and all the tests passed
BuildDetail.TestStatus = Microsoft.TeamFoundation.Build.Client.BuildPhaseStatus.Succeeded And
String.IsNullOrEmpty(DeployLocation) = False
The InvokeProcess filename property is
BuildDetail.DropLocation & "\_PublishedWebsites\" & WebSiteAssemblyName & "_Package\" & WebSiteAssemblyName & ".deploy.cmd"
Where “WebSiteAssemblyName” is a build argument the name of the Project that has been publish (I have not found a way to automatically detect it) e.g. BlackMarble.MyWebSite. This obviously as be set as an argument for the build if the deploy is to work
The arguments property is set to
"/M:http://" & DeployLocation & "/MSDEPLOYAGENTSERVICE /Y”
Again the “DeployLocation” is a build arguement that is the name of the server to deploy to e.g. MyServer
The Result property is set to an Integer build variable, so any error code can be returned in the WriteBuildError
This seems to work for me and I think it is neater than previous solution
I posted a while ago on using my Typemock TMockRunner Custom Activity for Team Build 2010. I left that post with the problem that if you wished to customise a template after you a had added the custom activity you had to use the somewhat complex branching model edit the XAML.
If you just followed the process in my post to put the build template in a new team project and tried to edit the XAML you got the following errors, an import namespace error and the associated inability to render part of the workflow
The best answer I have been able to find has been to put the custom activity into the GAC on the PC what you wish to edit the template on, just there nowhere else the method in the previous post is fine for build agents. So I strongly signed the custom activity assembly, used GACUTIL to put it in my GAC and was then able to load the template without any other alterations. I as also able to add it to my Visual Studio toolbox so that I could drop new instances of the external test runner onto the workflow.
The last of the recent batch of announcements is that of the first official release of the TFS Integration Platform. This provides tools to allow synchronisation between TFS 2010 and …..
- TFS 2008
- TFS 2010
- File System
Again more details on Brian Harry’s blog.