Its a non stop .net roller coaster

Visual Studio 2008 has only been out the door 5 minutes and there is a whole load of new technologies and CTPs flying out of the door. You barely get a chance to catch your breath the speed some of these are appearing.

Like most people I don’t have time to look at all of the new stuff on the horizon. But I’m most interested in:

Parallel Extensions to .Net Fx. I want to spend some time looking at this, i’ve got an interest in parallel programming and I really want to see what they’ve done here and how easy it makes it to make use of all those cores.

ASP.Net MVC. I been doing mainly WinForms and WPF work recently. Its been a little while since I did any ASP.Net so I really want to see how well this works. I did a bit of MVC when I had a dabble at Cocoa programming on the Mac. It’ll be intersting to see how ASP.Net MVC stacks up against the original asp.net page model. 

As I have a play with these i’ll post up a few musings and i’ll see if I can do something cool with them.

The Solution File is not an MSBuild file

Yes it is you say. Well you can do this:

msbuild mysolution.sln

and it does work. It will build all of your solution but it is not a true MsBuild file in the MsBuild format. The MSBuild engine has special code to deal with them. What it is actually doing is transforming the solution into a MsBuild file and running that.

Before you run it try this at the command prompt:

Set MSBuildEmitSolution = 1

This sets a special environment variable that MSBuild checks, if its set then it emits a copy of the transformed solution. Open this up and you will see what is happening when your build your solution. Its not very complicated, mainly just a bunch of calls to the MSBUILD task for the projects in the solution.

Calling a task with a list of files in MSBuild

MSBuild tasks can handle a list of files in several ways. Many of them will take them all in one go, through a single attribute. The list comes through as ITaskItem[] inside the task itself. We may not always want to call the task in this way, and not all support this. In some scenarios we might want to call the task once for each file.

Lets start by creating an itemgroup that defines all our files. Were going to give it the Name MyFiles and we’ll use a wildcard on the include attribute to select all the files in a directory.

<ItemGroup>
    <MyFiles Include="C:\Windows\Microsoft.NET\Framework\v2.0.50727\1033\*"/>
</ItemGroup>

A lot of targets in MSBuild can take a list seperated by semicolons. the CSC task for the C# compiler can take a list of source files in this way. To pass our list of files in this way we use the @(itemgroup) syntax, like this:

<Message Importance="normal" Text="@(MyFiles)"/>

In this example with the message task we our passing a single string with all our filenames seperated by semicolons.

Often what we actually want to do is call the task once for every file in the itemgroup. To do this we use the %(itemgroup.itemmetadata) syntax. In our itemgroup we haven’t defined any item metadata, fortunately msbuild provides some well known item metadata for us automatically. This includes such things as the file name, path, extension.

<Message Importance="normal" Text="%(MyFiles.FullPath)"/>        

Here we will call the message task once for every file and we will pass the full path.

The whole msbuild file:

<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
    <ItemGroup>
        <MyFiles Include="C:\Windows\Microsoft.NET\Framework\v2.0.50727\1033\*"/>
    </ItemGroup>
        
    <Target Name="Build">
        <!--Pass all in one call ';' seperated-->        
        <Message Importance="normal" Text="@(MyFiles)"/>

        <!--Call Target once for each file-->
        <Message Importance="normal" Text="%(MyFiles.FullPath)"/>        
    </Target>    
</Project>

When we run it with msbuild, we firstly get the output from the first call to the message task which received the text as a single string seperated by ‘;’. After this we have the output where it called the message target once for each file.

__________________________________________________
Project “C:\Temp\multiple.xml” (default targets):

Target Build:
    C:\Windows\Microsoft.NET\Framework\v2.0.50727\1033\alinkui.dll;C:\Windows\Mi
crosoft.NET\Framework\v2.0.50727\1033\cscompui.dll;C:\Windows\Microsoft.NET\Fram
ework\v2.0.50727\1033\CvtResUI.dll;C:\Windows\Microsoft.NET\Framework\v2.0.50727
\1033\vbc7ui.dll;C:\Windows\Microsoft.NET\Framework\v2.0.50727\1033\vjscui.dll;C
:\Windows\Microsoft.NET\Framework\v2.0.50727\1033\vjslibui.dll;C:\Windows\Micros
oft.NET\Framework\v2.0.50727\1033\Vsavb7rtUI.dll

    C:\Windows\Microsoft.NET\Framework\v2.0.50727\1033\alinkui.dll
    C:\Windows\Microsoft.NET\Framework\v2.0.50727\1033\cscompui.dll
    C:\Windows\Microsoft.NET\Framework\v2.0.50727\1033\CvtResUI.dll
    C:\Windows\Microsoft.NET\Framework\v2.0.50727\1033\vbc7ui.dll
    C:\Windows\Microsoft.NET\Framework\v2.0.50727\1033\vjscui.dll
    C:\Windows\Microsoft.NET\Framework\v2.0.50727\1033\vjslibui.dll
    C:\Windows\Microsoft.NET\Framework\v2.0.50727\1033\Vsavb7rtUI.dll

Build succeeded.
    0 Warning(s)
    0 Error(s)

Time Elapsed 00:00:00.05

Vista 64 support still missing in action for Canon’s RAW Codec

Being a proud owner of a Canon EOS 5D one of the first things I did after getting a new 64bit Vista machine was to go get the imaging codec from Canon for their digital SLR’s.

My enthusiasm was quickly destroyed when I found out that it was 32bit only. Fast forward a few months and Canon have just released a new version of the Codec that adds support for the likes of the 1D Mark III. But still no Vista 64 support. Come on Canon, sort this out. You’ve gone to the effort to write the codec, spend a little bit more effort to create a 64bit version. As our favourite pub land-lord would say: Shame on you Canon, Shame on you.

Here’s hoping you fix this for the next version.

Oh, and its not just Canon that doesn’t know Vista 64 bit exists, Nikon are just as bad.

WPF in the Enterprise

Most software developers don’t create off the shelf software packages, I’d hazard a guess that very few do. The reality is that most developers work on Line of Business applications, these are applications that have a user base measured in the hundreds, or the low thousands if your lucky. These are the applications where WPF needs to gain some traction.

These LOB applications are built to solve a business need and the sad fact about them is that the vast majority of them are ugly. There aren’t many Miss Worlds in the LOB realm.

If you take your average WinForms LOB application you’ll find a UI that is put together with minimal thought to the aesthetics. They’ll be a whole host of usability crimes and the visual style will be based around whatever the custom control package they’re using provides. The thing as a whole will have a lack of visual cohesion, which will be a function of the number of developers who worked on it. Its sad but true that most developers are rubbish at designing good UI’s.

Creating the UI for an average LOB application is fairly straightforward with Windows Forms. Everything we need is usually there. The tools, the framework and the environment are suited to the job at hand. Now this is the world where WPF has to live and thrive.

Here are some of my observations.

WPF is harder than WinForms.

There learning curve is steeper. Routed Events, dependency properties etc are not straight forward. Its not easy to pick up WPF quickly, and there isn’t much of your WinForms knowledge that has a high relevance in the world of WPF. Starting a new project with a team that hasn’t developed with WPF is going to require a reasonable amount of time to let them get up to speed with the technology.

Tool support is lacking.

The WinForms designer is very good. It’s intuitive to use and most people can just work it out without any intervention. The WPF designer in Visual Studio 2008 just isn’t up to the same standard. Lets look at the property windows for a button in the WinForms designer and the VS WPF Designer:

Windows Forms:

WPF:

To me Windows Forms is more intuitive, where are the events in VS WPF Designer, what the hell am I supposed to type in the BitmapEffectInput or Opacity mask properties? Where is the ‘…’ button that gives a dialog for setting these.

Its not all doom and gloom for WPF. Expression Blend is great, it works really well and is very stable. I know that Blend is pitched at designers but I think its great for developers too. Why did they create two designers; why doesn’t Visual Studio host a variant of the blend engine. They’ve done it for the Web designer in VS2008, that’s based on the core engine from Expression Web.

We don’t have designers

One of the big points that Microsoft wanted to get across when evangelizing WPF was the designer developer seperation and how WPF let them both easily co-exist within a project. For most LOB applications the developer is the designer. The problem is that they often have zero design ability. Eric Sink had a great post about WPF’s dirty secret, there is no golden ticket to a beautiful UI. Its just as easy to create an ugly app in WPF as it is with WinForms. There is no substitute for a bit of real graphical talent.

At times WPF makes it to easy to commit crimes against usability. Take Animation, its relatively straightforward to implement. But just because you can doesn’t mean that you should.

Here’s an idea, how about some pre-rolled styles with Visual Studio. The kind of thing that can be used to jazz up an otherwise dull application.

They rejected the animated 3D feature, they just want a grid instead.

Lets be honest, 3D is great and I love the fact that its so simple in WPF (well at least compared to the other ways of doing 3D). We want to create something that lets us play with these new features and dangle our feet in the world of quaternions but what we normally end up having to implement is a grid. Now the WPF grid is… yes, we all know there isn’t one.

Now I’m not trying to knock WPF. I think its a great technology. Its full of some amazing features and technologies: 3D, improved data binding, scalable UI’s, hardware rendering, proper text rendering, animation, documents and so on. It just isn’t going to automatically replace Windows Forms, there is still work that needs to be done to make it the default choice for every new project that involves some kind of desktop app. Its good to see announcements like the WPF Composite Client, these are the sort of things that we need to drive the adoption forward.

Heisenbugs and Schroedinbugs

While batteling with some random bugs on a Friday afternoon I remembered these particular classes of bugs. I think its the names that appeal to the inner geek in me. Clever names but very geeky.

If you can’t remember the details of these or you’ve never heard of them before here’s a quick recap.

Schroedinbugs

Named after the famous Schroedingers Cat thought experiment. A Schroedinbug is one that only appears when you read the code and find something that should not work. At this point it stops working even though it was previosuly working fine.

Heisenbug

This ones based on Heisenbergs uncertaintity principle. In which the act of observing affects the measurement of the thing being observed. In software this is a bug that appears but that act of trying to debug it makes it go away. Bugs that only appear in release versions of code are classic examples.

The Developers PC

Neons, Heatsinks that look like Taipei 101, water cooling, SLI, Crossfire and Over clocking are all de-rigueur in the world of gamers and modders but how much of that translates to the world of the developer.

All of these (except neons, — they’re just silly) are about getting every last bit of performance out of the PC. Making the machine as fast as possible.But there are downsides, the most notable being possible stability issues. The machine is pushed to the edge and if you’re not careful you can fall over.

At a completely different end of the PC market is the server. Servers need to be fast but they also need to be reliable, reliability is the King. Its all about uptime, a server going down costs money. Servers a built to be fast but more importantly they are built to be reliable. All of this comes at a cost, a lot of the parts that provide this reliabilty are expensive. And lets not forget the phenomenon which is the uber high-end workstation, or more simply the server class parts in a desktop chasis.

There are two schools of thought when it comes to the speed of the developer PC. One says give them the fastest possible, the other says give them the same hardware as your end users. That way they will produce software that will perform well on the type of machine that it is destined to be run on.

I sit in the first camp. Give developers the fastest machines possible, make them productive. Don’t let them sit around twiddling there thumbs while the compiler slowly churns through the code. It should be Quad Core, 4Gb RAM and 10,000RPM disks not some bog standard entry level Dell corporate desktop machine. If the average user spec machine is lower then get some of those machines to test on, not as primary dev machines. Create performance test that run on the lower spec machines, have performance bars that your software must meet. Don’t have developers continuously waiting for Visual Studio to catch up.

Where does the developer PC fit? I think the gamers approach is to close to the edge. The server/high-end workstation approach doesn’t offer value for money on the desktop. We need to live in some happy medium. 10,000RPM Raptors are fine, 15,000RPM SCSI drives aren’t worth the extra cash. Do we need 2GB of the fastest RAM around? Not really, we need lots of RAM. Buy more of the moderately fast RAM, and buy 4 or 8GB of it. Motherboards with dual 16x PCI-E slots are great and not because we can get some SLI action but because we can run 4 monitors. Give me two £150 graphics cards over one £300 card any day, I want to be able to run lots of monitors.

Welcome

I thought I should finally get round to creating a blog, and here it finally is.

I’m going to be rambling about c#, .net, wpf, msbuild, powershell and what ever other technologies take my fancy.