.Net Code Monkey RSS 2.0
 Thursday, May 05, 2016

Volkswagen 2007 Transporter 2.5 TDi BNZ Engine Alternator Auxiliary Shaft Failure

Today I want to discuss a couple of failures. The first failure is the root cause which caused my recently purchased second hand Volkswagen Transporter Shuttle to leak a lot of oil when the engine is running. The second failure is VW’s inadequate level of service when it comes to keeping the part in stock that was the root cause of the issue, meaning their only option was to suggest a full short or long block at circa £3.5k or £6.5k respectively!

So before I go full rant let’s step back a bit to when I purchased the bus. I purchased the Transporter Shuttle off a “trader” who advertised the van on AutoTrader as having good history and only 91k miles. Long story short I was seen off and the “trader” walked off with the documented history and on my way home with the van the various issues started to show their head, like various engine warning lights! Further issues have indicated this is unlikely to be a 91k mileage van!

One of the issues that was not immediately apparent until the day after I parked it on the drive was the pool of oil under it. This was traced by a mechanic to a seal on the alternator auxiliary drive shaft. This seal was ordered from VW and replaced, not an easy job as half the front end and radiator need to be removed for access. The mechanic noticed the shaft had a bit of play, but hopefully not too much to cause any problems. They ran the engine up and the leak seemed to have abated. Thank goodness.

However 30 miles later the oil was once again running out past the new seal. Now this shaft is driven from the crank via a set of gears which drive other auxiliary shafts. So this time to get to the bottom of the issue its gearbox off time to get full access to the shaft. What we found was although the shaft a little wear at the bearing points it had 0.4mm wear at the point where the rubber seal touched the shaft. I can only assume due to the suspected VERY high mileage of the engine the original seal must have worn right out and the metal “spring” which holds the seal lip against the shaft from inside the seal must have burst through the rubber lip and started to wear a groove in the shaft.

This shaft has a VW part number 070 903 325 C. So I contacted both  my local TPS and Volkswagen dealer, but both advised that this part is not available and I’d require either a short block or a long block at circa £3.5k or £6.5k (+VAT I assume!). Well I had only just bought the van for £7k so was not willing to spend £4k plus labour on a new engine. I cannot believe that VW do not keep any of these parts available for purchase. They must have made enough for spare engines, so why not run a few hundred off to keep as spares to sell. Do they really think it is acceptable to demand that an owner whose shaft has failed purchases a brand new engine from them? This to me seems a bit of a failure in customer service!

So my next port of call was the internet. Trawling the internet did not turn up much either except for this thread on a VW forum. It seems this guys does not have the same problem but did need a new shaft and bolt. I also found this thread where the guy also had an oil leak.

I could not find much evidence anywhere else except a Chec site which I could not read. Using information from one of the guys in the first thread i did speak to a guy called Paul at Carneil Precision in Staveley, Chesterfield S43 3PE. He was very helpful and said he would be able to make one if I sent him the part. If i had been based up near chesterfield I would have paid him a visit with the offending part. As it is I am on the south coast so took the part to a local engineer, Matt who is the proprietor of White Engineering, Portland, Dorset. He turned up the part out of a very hard material and it is now with the my mechanic waiting to be refitted.

So what is my gripe? Well mainly that i’m sure it would not have hurt VW to have made an extra number and kept some back for after sales service. I’m sure in the batches they must have had made for this engine it would have been pounds only or a couple of tens of pounds at least! I think it is a failure of customer service for VW to believe that the failure of such a small piece should result in a sale of half an engine, or a full engine.

So to sum up

Do I still love my VW transporter? Just about.
Will I be keeping it much longer? Possibly.

Will i buy another Transporter in the future? Unlikely.

Will i buy another VW in the future? Unlikely.

Part Reference

Some of these may not be correct. Suggest you check first!

  • Bolt VN 909 797 05 £1.54 + VAT
  • Alternator drive Hub V070 903 115 C £23.33 + VAT
  • Hub (Not sure if this is the shaft or the Gates coupling pulley!) 070 903 115 E
  • Could this be the part no shaft?   070 903 325b
  • Believed to be part number for seal 070 903 107

Thursday, May 05, 2016 7:43:10 PM (GMT Standard Time, UTC+00:00)  #    Comments [0] -
070903325 | transporter | Volkswagen
 Friday, February 19, 2016
# Centralised Event Dispatcher in C# - Part 4
This is part four of a series of posts where I am going to share with you the solution I have used in a recent project for a centralised event dispatcher. All of the source code will be available in my public GitHub repositories. The concept I have tried to realise is a central class that can raise events for any listener to subscribe to.

In part one we created the event dispatcher class library.
In part two we consumed it from a windows forms application.
In part three we look at adding pooling for commonly raised events and implement an 'ApplicationEventPool'.

In this part we will were going to be looking at applying a restriction on what events can be safely pooled. However further investigation following feedback on the articles has indicated that there may be little to gain from pooling the events, so until a better reason presents itself to continue investigating pooling I am going to bring this series to a close here.

Friday, February 19, 2016 6:43:15 AM (GMT Standard Time, UTC+00:00)  #    Comments [0] -
.Net | C# | Event Dispatcher | Event Handling | Events
 Friday, February 12, 2016

Using ReSharper Tool to Create an Immutable Class

If you have the JetBrains ReSharper tool for Visual Studio it is a trivial task to create a whole immutable class from a single line constructing the object before a class representing the object even exists in your solution.


Given the following line, and assuming that no class called `MessageEvent` already exists anywhere in your Visual Studio project solution.

var @event = new MessageEvent(sender, CreateMessageTextBox.Text);

Create a new class from the constructor call

Click on the `MessageEvent` constructor word. Observe the red reSharper light bulb in the left margin and mouse-over it. You will see a tool tip "Create type 'MessageEvent' (Alt + Enter)". Click the "Create type 'MessageEvent'" option and this will create a new class of this type in the current file. Select "class" or "struct", then tab through the constructor argument types and names, changing as required. Clear out the `throw new System.NotImplementedException();` from the constructor.

internal class MessageEvent
     public MessageEvent(object sender, string text)

Move the class to its own file

Click on the class type name, in this case `MessageEvent`, observer the reSharpoer hammer in the left margin and use the "Move to 'MessageEvent.cs'" to create the class in its own file. Using Visual Studio Solution Explorer, move the `MessageEvent.cs` to your preferred location.

Correct the class namespace

Click on the class namespace and use the ReSharper light bulb in the left margin to adjust the namespace to suit the location or correct it manually.

Introduce Fields for the Constructor Arguments

Click on each field and use the ReSharper light bulb in the left margin to "Introduce and initialize field"

internal class MessageEvent
     private readonly object _sender;
     private readonly string _text;

     public MessageEvent(object sender, string text)
         _sender = sender;
         _text = text;

Encapsulate field

Click on the field name and use the ReSharper light bulb in the left margin to "Encapsulate Field". Select the appropriate options, scope usage, etc, in this case I will just use "Read Usages".

internal class MessageEvent
     private readonly object _sender;
     private readonly string _text;

     public MessageEvent(object sender, string text)
         _sender = sender;
         _text = text;

     public object Sender
         get { return _sender; }

     public string Text
         get { return _text; }
And there you have it. An immutable class created with ease from a single constructor statement using ReSharper. Enjoy your new found productivity!

ReSharper Download

You can download a free 30 day trial of JetBrains ReSharper here.
Friday, February 12, 2016 5:35:10 AM (GMT Standard Time, UTC+00:00)  #    Comments [0] -
.Net | C# | CodeProject | Visual Studio 2012 | JetBrains ReSharper | Visual Studio | Productivity
 Thursday, February 11, 2016

Centralised Event Dispatcher in C# - Part 3

This is part three of a series of posts where I am going to share with you the solution I have used in a recent project for a centralised event dispatcher. All of the source code will be available in my public GitHub repositories. The concept I have tried to realise is a central class that can raise events for any listener to subscribe to.

In part one we created the event dispatcher class library, in part two we consumed it from a windows forms application. In this part we are going to look at pooling commonly raised events and implement an 'ApplicationEventPool'.

UPDATE: Please note that following feedback from others, and during the creation of part 4 the event pooling was not found to give much advantage, so you may wish not to read any further of this article.


It is assumed that the reader of this article already has a good understanding of coding with C#, can create projects and solutions, classes and Windows Forms, and can add references to a project and import references into a class. It is also assumed the reader understands basic inheritance and interface implementation.

So one of the issues with the solution we currently have is as the system grows the number of events being raised may grow astronomically, and if each event raised creates a new instance then a memory concious system may start to "sweat" especially if the event data is quite large.

With this in mind we can look to minimise this slightly by allowing the system to pool commonly used events.


So lets move back into the core class library and see if we can implement a system to pool some of the commonly used events.

First lets define the contract which we think we are going to need for an object that pools Application Events. In the `Contracts` folder we will create a new interface named `IApplicationEventPool`. We probably need a method to try to add an event, one to try and get an event, one to try and remove and event, and a last to remove all events.
public interface IApplicationEventPool
    bool TryAdd<TEvent>(TEvent @event) where TEvent : class, IApplicationEvent;
    bool TryGet<TEvent>(out TEvent @event) where TEvent : class, IApplicationEvent;
    bool TryRemove<TEvent>(out TEvent @event) where TEvent : class, IApplicationEvent;
    void Clear();
For a class which implements this contract:
* `TryAdd` should try and add an event to the backing store of the class if an event of that specified type does not exist.
* `TryGet` should retrieve an event of the specified type if one exists in the backing store
* `TryRemove` should remove an event of the specified type from the backing store if it exists.
* `RemoveAll` should remove all events from the backings store

So now we can create the implementation of the interface as the `ApplicationEventPool` class. This will require a backing store which will be a dictionary with the key which will be a `System.Type` and a value which will be of `IApplicationEvent`
public class ApplicationEventPool : IApplicationEventPool
        private readonly Dictionary<Type, IApplicationEvent> _applicationEvents;

        public ApplicationEventPool()
            _applicationEvents = new Dictionary<Type, IApplicationEvent>();

        public bool TryAdd<TEvent>(TEvent @event) where TEvent : class, IApplicationEvent
            if (@event == null) throw new ArgumentNullException("event");

            Type eventType = typeof(TEvent);
            if (_applicationEvents.ContainsKey(eventType)) return false;

            _applicationEvents.Add(eventType, @event);

            return true;

        public bool TryGet<TEvent>(out TEvent @event) where TEvent : class, IApplicationEvent
            Type eventType = typeof(TEvent);
            IApplicationEvent applicationEvent;
            @event = null;

            if (_applicationEvents.TryGetValue(eventType, out applicationEvent))
                @event = applicationEvent as TEvent;

            bool eventFound = (@event != null);
            return eventFound;

        public bool TryRemove(Type eventType) //where TEvent : class, IApplicationEvent
            throw new NotImplementedException();

        public void Clear()
PLEASE NOTE: A set of units tests for the above class can be found in the `ApplicationEventPoolTests` class of the `Dibware.EventDispatcher.Core.Tests` in the repository.

Now we have an ApplicationEventPoolObject lets switch back to the UI project and set up a scenario which could use it.


Lets add a new button to the main form and name it `HelloWorldButton` and give it the text of "Hello World!". Now create a button click handler for the new button. In the handler lets use the `ApplicationEventDispatcher` to raise a new event called `HelloWorldShouted`.
private void HelloWorldButton_Click(object sender, EventArgs e)
     ApplicationEventDispatcher.Dispatch(new HelloWorldShouted());
As we haven't got an event called `HelloWorldShouted`, we had better create one in the `Events` folder.
internal class HelloWorldShouted : IApplicationEvent
     public string Message
         get { return "Hello, you event driven world, you!"; }
Now we need to add a handler method to the main Form controller and wire it up and un-wire it in the `WireUpApplicationEventHandlers` and `UnwireApplicationEventHandlers` methods respectively.
protected override void UnwireApplicationEventHandlers()

 protected override sealed void WireUpApplicationEventHandlers()
Put a break point in the 'HelloWorldButton_Click' method of the `MainForm`, run the application and click the `HelloWorldButton` a few times. you will need to close the message box each time of course! You will likely notice that a new `HelloWorldShouted` event object is created each time. Each time this event is instantiated, it is exactly the same as the last, so this may be a good candidate for using our `ApplicationEventPool`. Lets have a look at implementing this.

In the `MainProcess` we will create a new private field of interface type `IApplicationEventPool` and initialise it in the constructor as the concrete class `ApplicationEventPool`. we will also pass a reference to the `MainFormController` via it's constructor as the interface `IApplicationEventPool`. This will allow us later to swap out the `ApplicationEventPool` for another should we want to for testing or enhancement purposes.
internal class MainProcess : ApplicationEventHandlingBase
     private readonly MainFormController _mainFormController;
     private readonly IApplicationEventPool _applicationEventPool;

     public MainProcess(IApplicationEventDispatcher applicationEventDispatcher)
         : base(applicationEventDispatcher)
         _applicationEventPool = new ApplicationEventPool();
         _mainFormController = new MainFormController(applicationEventDispatcher, _applicationEventPool);
In the `MainFormController` we will cache the `IApplicationEventPool` before passing the reference on once more to the `MainForm`.
private readonly IApplicationEventPool _applicationEventPool;
private MainForm _mainForm;

public MainFormController(IApplicationEventDispatcher applicationEventDispatcher,
     IApplicationEventPool applicationEventPool)
     : base(applicationEventDispatcher)

     _applicationEventPool = applicationEventPool;
     _mainForm = new MainForm(applicationEventDispatcher, applicationEventPool);

Finally in the `MainForm` we will cache the `IApplicationEventPool` once more so it can be access throughout the form code.
private readonly IApplicationEventPool _applicationEventPool;

 public MainForm(IApplicationEventDispatcher applicationEventDispatcher,
     IApplicationEventPool applicationEventPool)
     : base(applicationEventDispatcher)
Now we have a reference to the `ApplicationEventPool` in the `MainForm` lets modify the code in the `HelloWorldButton_Click` button handler method.
private void HelloWorldButton_Click(object sender, EventArgs e)
     HelloWorldShouted @event;

     var eventAlreadyCached = _applicationEventPool.TryGet(out @event);
     if (!eventAlreadyCached)
         @event = new HelloWorldShouted();

So now we declare an event but we wont instantiate it yet. We will try and get this event from the `ApplicationEventPool` and if it exists we will pass that to teh event dispatcher, but if one does not exist then we will create one and pass that instead.


We do have an small clean-up task to do in the `MainProcess` where the `ApplicationEventPool` was instantiated. We must clear the pool in the `Dispose(bool)` method.
protected override void Dispose(bool disposing)
     if (Disposed) return;

     if (disposing)
         // Free other managed objects that implement IDisposable only

     // release any unmanaged objects
     // set the object references to null

     Disposed = true;


So now we can reuse any common events through the lifetime of the application. However we are not out of the woods yet. Why? Well, this event pool is great for simple events, that carry no data or immutable data that will be the same for each time the event is dispatched but what if our events are mutable or immutable after construction? We can't trust that they will be in the right state when we dispatch them so two class could dispatch the event and require different data within the event. so how will we handle that? Well we will look at handling them in the next part, part 4.

Disclaimer - Memory Usage

I am not an expert on Garbage Collection, so please be aware that pooling may not be the best solution for a memory problem using this Event Dispatcher. Pooling may lead to objects that should be short lived and would normally live in Generation 0 and get reclaimed quickly, being moved to Generation 1 or 2 and maybe not being reclaimed until the process ends. You can use `PerfMon.exe` or other profiling tools to help identify memory issues, and make an informed decision on how to combat them.

For further information on the Garbage Collector and [Garbage Collector Generations](https://msdn.microsoft.com/en-us/library/ee787088(v=vs.110).aspx#generations) please see [Fundamentals of Garbage Collection](https://msdn.microsoft.com/en-us/library/ee787088(v=vs.110).aspx)

Part One
Part Two
Thursday, February 11, 2016 10:13:32 PM (GMT Standard Time, UTC+00:00)  #    Comments [0] -
.Net | C# | CodeProject | Event Handling | Events | Windows Forms
<June 2016>
Creator of ruby on Rails
 Harry Pierson
Passion * Technology * Ruthless Competence
 Joshua Flanagan
A .NET Software Developer
 Martin Ffowler
Author, speaker, and loud-mouth on the design of enterprise software
 Michael Schwarz's Blog
Developing applications on the Microsoft platform since Windows 3.1!
 Scot GU
Scott Guthrie lives in Seattle and builds a few products for Microsoft
 Scott Hanselman
Programming Life and the Zen of Computers
About the author/Disclaimer

The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.

© Copyright 2016
Duane Wingett
Sign In
Total Posts: 84
This Year: 6
This Month: 0
This Week: 0
Comments: 61
Pick a theme:
All Content © 2016, Duane Wingett
DasBlog theme 'Business' created by Christoph De Baene (delarou)