The blogs of Black Marble staff

The joy of XP Media Center Edition

I decided to build a MCE PC for home (replacing a £200 DigiFusion PVR), I thought how hard can it be, it is just XP and a TV card.

I don't intend to go into the gory details of the build, suffice it to say one blown motherboard and a true understanding that this is an OEM product (for dedicated hardware) not for the home builder, but I can provide a few pointers:

  • My PC specification seems reasonable, an AMD Sempron 3100+, 1Gb memory, large IDE disk and an ATI Radeon 9600 AGP card. It averages out at about 20% utilisation, so little more than tickover
  • Firstly the MCE setup video failed to play, this turned out to be the wrong ATI drivers, make sure whichever card you are using you have MCE specific drivers, even if they are a bit old.
  • Initially I had jumpy playback on live TV and recordings, I was using a Hauppauge DVB card and the NVidia decoder. After much playing with drivers I fix this by, believe it or not, moving the PCI TV card to a slot as far from the AGP video card as possible.
  • On some digital TV channels on the MCE it was still jumpy, my Phillips integrated digital TV was better (but not perfect), a cheap TV ariel amplifier fixed the problems. Note that this is even though both the TV and MCE said the TV signal strength was excellent!
  • I had built the PC using an old case, but wanted to get something that was quiet and could be put in the lounge not a machine room. I fancied a totally passively cooled unit, but decided that spending more on the a metal box, PSU and heat sinks than on the actual TV could not be justified, so I ended up with a D-Vine D5 Case with PSU and a Zalman CNPS7000B Series Super Flower Cooler. The CPU cooler is really quiet, but the case PSU could be quieter, but it is certainly much quieter than a standard PC. The worst item for noise was the fan on the ATI card, I looked at passive heatskins, but as the card did not seem to be running hot I just disconnected the fan (all seems OK after a week, it is not even hot to touch!).  I may experiment inside the main PSU to see what can be done there with disconnections.

So has it all been worth the effort? I would say yes - MCE is a nice interface, the TV guide is excellent. If you buy a custom built system, or are a keen, experienced system builder and want a project it is perfect. However if you want an quick easy way to record digitial TV look at a PVR from Humax or DigiFusion.


Office Developer Conference 2006

I had a great time at the Office Developer Conference in Hammersmith last week.  It covered Infopath 12, SharePoint V3 and Workflow, some of my hot topics at the moment.

It was great to put faces to names (and bloggers) like Dave Gristwood, and to see a few others speak again (like Mike Ormond).  I also enjoyed Jessica Gruber's sessions, and will be reading her blog from now on too.

Were you there?



The Horror the beautiful horror of moving EVC 4 projects to Visual Studio 2005

I have just finished moving a large Embedded Visual Studio 4 (MFC) project to Visual Studio 2005. It was somewhat a painful experienece which I would not want others to have to endure.

I am sure anybody else will have different problems but the solutions that helped me were

1. build a new Visual Studio 2005 MFC application

2. migrate the old app by opening it in VIsual Studio 2005 ( save the app )

3. delete all the code in the new application exept Stdafx.h

4. compare and merge your old stdafx.h and the new one ( really this should mean replacing your stfafx.h )

5 fix remaining build errors, the new compilers are great and will find enough embarrassing errors to make the exercise worth while. you will most likely have a few problems with SEH and sh* functions but they do drop out.

Doing the above will save you a lot of time, the changes in stdafx are quite extensive.

If you are running IE 7 before the steps above you will need to edit your registry

To add a new entry to


This will allow the mobile wizard to use the IE 7 html control

The end results are an application which is approx 10-20% faster and we have intellisense woo hoo.



//   ::CommandBar_Show(m_pWndEmptyCB->m_hWnd, FALSE);// 2005 port

   HWND cmdBar=::SHFindMenuBar(this->GetSafeHwnd());


Dell Inspiron 5150 Running Hot and VPCs running slow

I had to have a new motherboard in my Dell 5150 laptop, one of the memory slots failed on the old one. Since the repair my laptop seems to have been running hot. Also when using Virtual PC 2004 SP1 the sessions seems to pause for a second or two from time to time.

I have tried the hotfix for VPC 2004 and this seemed to help the speed a bit (but not as much as I would have hoped), but my PC still seemed a lot hotter than it used to be.

I installed the excellent I8KFanGUI to get an idea of what was going on, and found that I seems to always be running at top CPU speed 3GHz, so no smartstepping slowing me down (oftan blamed for slow VPC performance), and the fans seems to be doing sensible things. However, my average CPU temp was about 55C with a max of 71C.

I read round a bit and found a number of people with CPU temp problems with the newer BIOS (A37/A38), so I downgraded to BIOS A35 (which I think my old motherboard had) and low and behold my idling temp dropped by nearly 10 degrees to 47C. My max is about the same.

So at least I don't have to prop up my PC on a book to avoid thermal shutdown, I just need a better solution to the VPC speed problem, I suspect a networking polling issue.

SourceSafe and CruiseControl

A day or so ago our CruiseControl stopped working, I was seeing loads of problems in the Get source stage. Basically it was timing out, but it had work last week! OK I had been trying to get MsTest  integrated but that should not have effected the source control.

After much fiddling including:

  • Creating a new VSS DB (very small one)
  • Moving the DB to a different server
  • Trying VSS 6.0 and VSS 2005 clients

I pinned the problem down to a networking issue (the new small VSS DB worked OK if local on the same box as CCNet, but not across a 1Gb LAN to another 2003 Server).

More digging found the issue was our Mcafee VirusScan 8. My guess is that an automatic update last week caused the problem, it must have swiched something on, or change the load level it cause.

So in the end the simple fix was to switch off the Mcafee VirusScan On-Access Scanner's file reads checking the problems all go away.



MSTest and CruiseControl .NET

I have been trying to get Visual Studio 2005 Team Developer style unit tests working within CruiseControl.

The documention says it should work, but is a little scant as to the detail of how to do it. So now I have it all going I thought an example of the working ccnet.config file with some comments might help other people trying to get this going.

So the background is I have a VS.NET 2005 solution (My Sample.sln) with some projects in it. One of these is a Test Project (TestProject.csproj). This contains some test which can be run via the Test menu option is VS.NET.


<project name="My Sample">
<!--Here you put any other project level settings-->
<!--the working directory is used for all relative file references-->

<workingDirectory>C:\projects\My Sample</workingDirectory>

<!--Normally you would have all your source control bits here-->

    <!--We use the Visual Studio build model, you could also use the MSBUILD-->
solutionfile>"C:\projects\My Sample\My Sample.sln"</solutionfile>
            <!--Comment out the project block so it build the whole solution-->
executable>"C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\"</executable>

            <!--Call a batch file that contains del testResults.trx -->
            <!--this is required as MsTest will not create the file if it exists-->
            <!--this could be merged with the mstext action in a single batch file-->
baseDirectory>C:\projects\My Sample</baseDirectory>

            <!--Call mstest to run the tests contained in the TestProject -->
executable>C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\mstest.exe</executable>
baseDirectory>C:\projects\My Sample</baseDirectory>
            <!--testcontainer: points to the DLL that contains the tests -->
            <!--runconfig: points to solutions testrunconfig that is created by, list what test to run -->
            <!--resultsfile: normally the test run log is written to the uniquely named testresults directory  -->
            <!--                   this option causes a fixed name copy of the file to be written as well -->
buildArgs>/testcontainer:testproject\bin\debug\testproject.dll /runconfig:localtestrun.Testrunconfig /resultsfile:testResults.trx</buildArgs>


         <!--to get the test results in the dashboard we have to merge the results XML file -->
         <!--the project working directory is used as the base path here -->
         <!--this is the line I missed for ages, without it you get strange missing publisher log errors -->
xmllogger />



By default with CCNET build 1277 has the entry to display MSTest results in the summary. If you want the results on a separate menu item (like nUnit or FxCop) then the dashboard.config should contain the following bits

<!--all these xsl entries are in the 1277 build -->

<buildLogBuildPlugin />
xslReportBuildPlugin description="NUnit Details" actionName="NUnitDetailsBuildReport" xslFileName="xsl\tests.xsl" />
xslReportBuildPlugin description="NUnit Timings" actionName="NUnitTimingsBuildReport" xslFileName="xsl\timing.xsl" />
xslReportBuildPlugin description="NAnt Output" actionName="NAntOutputBuildReport" xslFileName="xsl\Nant.xsl" />
xslReportBuildPlugin description="NAnt Timings" actionName="NAntTimingsBuildReport" xslFileName="xsl\NantTiming.xsl" />
xslReportBuildPlugin description="FxCop Report" actionName="FxCopBuildReport" xslFileName="xsl\FxCopReport.xsl" />
xslReportBuildPlugin description="NCover Report" actionName="NCoverBuildReport" xslFileName="xsl\NCover.xsl" />
xslReportBuildPlugin description="Simian Report" actionName="SimianBuildReport" xslFileName="xsl\SimianReport.xsl"/>
   <!--add the following line to add the extra menu item-->
xslReportBuildPlugin description="MSTest Report" actionName="MSTESTReport" xslFileName="xsl\MsTestSummary.xsl"/>

More on the .NET 2.0 and .NET 3.5 Comparison

In my demo last week I extended a string class; I am pleased to say that after some ( quick ) investigation as predicted the calls to the class are identical.

To explain extensions we can use the following code

class Fred {

   string MyStringMethod ( string s ) {

      // do something



string x = Fred.MyStringMethod(x);

Using extensions we can change the definition of the method MyStringMethod to use this

   string MyStringMethod ( this string s )

this allows us to call it in a more friendly manner

string x = x.MyStringMethod();

as if it were a member of string.

When looking at the code generated there is No difference in the invocation i.e., it always calls Fred.MyStringMethod. the only change to code is the attribute added to the MyStringMethod

[Extension] attribute which has been attend to the method which shows that it is an extension method.

All I can say is I think that the language designers at Microsoft have done another great seamless job on adding features.

I have not been able to add the attribute by hand at this point.


Comparison of .NET 2.0 and .NET 3.5

Last Saturday I presented on LINQ at Developer Developer Developer. I stated that that much of LINQ was syntactic sugar ( very good low fat sugar) and in fact much of the work being done by the compiler effectively did repetetive work that we do day to day.

I see this as very solid reoccurring theme in Microsoft development tools, if the developer is doing the same thing again and again, visual studio will aim to help without being too prescriptive.

During the talk I confidently stated that the compiler really was generating much the same or possibly identical code, I suggested that the attendees could look at home but somehow I ended up offering to do the job so here are some rough notes.

taking the two snippets of code

for .Net 2.0

List<int> list = new List<int>();


            List<int> evenNumbers = list.FindAll(delegate(int i) { return (i % 2) == 0; });

            foreach (int evenNumber in evenNumbers)




and its LINQ equivalent

            var list = new List<int>() { 1,2,3,4};

            var evenNumbers = list.FindAll(i=>(i % 2) == 0);

            foreach (var evenNumber in evenNumbers)




looking at the IL code that is generated for the anonymous delegate / lamda function we see that the code is identical for both

.method private hidebysig static bool <Main3>b__2(int32 i) cil managed


      .custom instance void [mscorlib]System.Runtime.CompilerServices.CompilerGeneratedAttribute::.ctor()

      .maxstack 2

      .locals init (

            [0] bool flag1)

      L_0000: nop

      L_0001: ldarg.0

      L_0002: ldc.i4.2

      L_0003: rem

      L_0004: ldc.i4.0

      L_0005: ceq

      L_0007: stloc.0

      L_0008: br.s L_000a

      L_000a: ldloc.0

      L_000b: ret


which is the equivalent to


private static bool <Main3>b__2(int i)


      return ((i % 2) == 0);


Obviously the method name changes but that is the only change.

For the main block of code the only difference is the LINQ code generates a temporary List, populates it and then assigns it to the variable list. I can only assume that this is the implementation method of assignment, but I would hope it will come out in the wash, not that in the grand scheme it matters, but it would be a bit tidier.

I will be looking at other examples and posting my findings over the next week or so.


WinFX 3.0 is now .Net Framework 3.0

WinFX 3.0 is now .Net Framework 3.0

With the aim of providing us with consistency Soma has announced that from now on WinFX consisting of Windows Presentation Framework (Avalon) , Windows Communications Framework (Indigo) , Windows Workflow Foundation (WinOE) and Cardspace ( the product formaly known as Infocard ) will be known as .Net Framework 3.0

It looks as though .NET 3.0 will be dependant on .NET 2.0 and should not download the runtime as well.

Soma previously has indicated a red/green model for classifying the .NET runtime and its supporting assemblies. Red assemblies include .NET itself and what was WinFX 3.0 , Red assemblys will be subject to a service pack style compatiblity and wherever possible backwards compatiblity. Green assemblys will be new and can be thought of as additions. One can only assume that over time Green assemblys will migrate to Red.

I can only assume that the LINQ addions will now come in .NET Framework 3.5.

Loading test data files in Microsoft Test Projects without fixed paths

I sorted a problem today that has been going on a while, how to load test data in unit tests without resorting to fixed paths.

We had an class library assembly and an associated test project in Visual Studio 2005 Team Developer Edition. The problem was the methods we needed to test (via a unit test) had to load some data from a file at run time.

In the 'real' application the file was loaded using the code

     string filename = Application.StartupPath + \\datafile.dat";     

This all worked fine, as the data file was included in the project and set to be 'contents' so copied with the assembly to the build directory. (It was not put in a resource bundle as the user many need to edit the file with other tools)

So I wrote my unit test for one of these methods, ran it and it failed (OK I know I should have written the test first to true TDD). The reason the test failed was because the Application.StartupPath was that of the running application's path, not the assembly under test i.e. Visual Studio in. C:\Program Files\Microsoft Visual Studio 8\Common7\IDE.

To fix this problem took two steps. The first was to alter the logic to load the data file to use the path of the assembly containing the function under test (not the path of the application that is calling the assembly)

    string filepath = System.Reflection.Assembly.GetExecutingAssembly().Location;
    filepath = filepath.Substring(0,filepath.LastIndexOf("\\"));

First I tested my 'real' application and it still worked, so I  re- ran the test and it still failed. This for a while had me consfused until I realised that the way the tester instide Visual Studio works is that it copies the files to a special test directory, each test run will create a new directory.

I realised that the tester copies all the assemblies in the project - BUT NOT ANY OTHER CONTENTS FILES. The fix was to edit the test configuration file (found on the test menu, the the edit test run configuration file). On the deployment tab add the test data files. Once this is done the files will be copied with the assemblies and the test started to work.

Now to look to get the running of unit tests to be part of the build process.