So ever since I have started working with Visual Studio 2008 I find myself hitting shortcut keys that just don't exist anymore.  I have been denied my ReSharper abilities and it is really humiliating to work without them, I miss my ReSharper.  But soon, very soon in fact by February 15th the good folks at JetBrains will be opening up the Early Access Program for ReSharper 4 and not soon enough! 

Thank god! That is all I have to say, working with ReSharper substantially improves my code quality and code output. You can read all about this on ReSharper Horizons blog.

So I have been exploring DI Frameworks lately (Dependency Injection), and there are a couple of solutions.  While I kind of like the metadata approach vs. the XML Configuration one there really isn't anything available yet.  You have ObjectBuilder, but its only a DI Framework, it doesn't include a DI Container so you are left to build your own container, which includes setting up all of your strategies, context, etc.  The CodePlex guys are apparently working on an ObjectBuilder v2 which they are trying to get vetted by the P&P team at Microsoft.

So the choices are:
Spring.NET
StructureMap
Castle Windsor Container

I have been evaluating these mostly because of a hobby project I am working on called VistaTune, I would like to use a DI Framework and the current changeset that is checked in is using Spring.NET but I am not happy with Spring.NET for a couple of reasons.  First there is no real way to control your dependency injection dynamically, its all configuration based.  Secondly there is no way to inject an instance into your container, for example during unit testing I would like to inject a mock to override the real instance that is mapped in the configuration.  Thirdly there is no DSL (Domain Specific Language), and appears to be no DSL planned for the future release.

Note: After posting this Jeremy D. Miller the developer of StructureMap updated me, the current version of StructureMap v2.0 already has DSL but the next version is being extended with even more.  See the comments section below, also visit his blog here for more information.

For those reasons, I am leaning towards using StuctureMap, which in current release has no DSL but next release will which is already in testing so its pretty much done.  It supports container injection, and it allows you to reset your injection so you can revert back to the original container before injection which is really cool.  It also supports interception, among other things that are out of the scope of my assessment.

So which DI Framework?  It is a difficult question to answer, and I really think it will be interesting to see what comes about from the current top runners at the moment.  I expect to see big things from Microsoft on ObjectBuilder, especially since they just released their PIAB (Policy Injection Application Block) which is their solution to an AOP (Aspect Oriented Programming) Framework.  I would personally rather see PIAB stay isolated by itself, I prefer small isolated Frameworks rather than huge bloated ones that you only want to use for a single thing. 

Ok, so the previous post I discussed a service locator implementation based on the Martin Fowler registry example.  After some thought and discussion with a couple of friends I decided the previous implementation was a bit too strict for it's own good.  So I have come with a way that still gives you generic goodness, it does however suffer from boxing/unboxing which may give you a slight performance penalty vs. my previous implementation but the penalty should be minimal if noticeable at all.

The new service locator implementation:

  public interface IService { }
    public class ServiceLocator
    {
        private static ServiceLocator _instance;
        private ServiceLocator() { }

        private static Dictionary<string, object> _map = new Dictionary<string, object>();

        public static ServiceLocator Instance
        {
            get
            {
                if (_instance == null)
                {
                    _instance = new ServiceLocator();
                }
                return _instance;
            }
        }

        public void Load<T>(T service) where T: IService
        {
            Load(typeof(T).FullName, service);
        }

        public void Load<T>(string key, T service) where T : IService
        {
            _map.Add(key, service);
        }

        public T Get<T>() where T : IService
        {
            return Get<T>(typeof(T).FullName);
        }

        public T Get<T>(string key) where T : IService
        {
            return (T)_map[key];
        }
    }

To use this the syntax is slightly different than before, this time everything is method based.  I still constrain the methods to the IService type, for some reason  it just gives me a warm and fuzzy feeling when I use the constraint. It is obviously up to you whether or not you want to use it, you could delete the marker interface and the constraints completely and it will work just fine.

To Get: MyService wmiService = ServiceLocator.Instance.Get<MyService>();
To Load: ServiceLocator.Instance.Load<WMIService>(new WMIService());

So both versions work, both versions are acceptable solutions but this one is more flexible than the last version.  In particular this version allows a greater degree of flexibility around unit testing and mocking frameworks.

So I came across the need for a service locator but I didn't want to use a framework since my needs were relatively lightweight, and mostly based around testing.  So looking at Martin Fowlers examples of Service Locators I adopted them and came up with a .NET way of doing it using Generics.  It is of course flexible, the method I am offering obviously has a couple of constraints that I have put in place on purpose for my scenario.  One of them being I wanted only one instance of a service set in the service locator at any given time, so you could very easily adapt it to suit your own needs. 

Also the interface specified is a marker interface used to specify a constraint on the generic, the idea was that all services would be marked with this interface.

 public interface IService { }

    public class ServiceLocator<T> where T : IService
    {
        private static Dictionary<string, T> _map = new Dictionary<string, T>();
        private ServiceLocator() { }

        public static void Load(T service)
        {
           _map.Add(typeof(T).FullName, service);
        }

        public static T Get()
        {
            return _map[typeof(T).FullName];
        }
    }

An example of a service would be like follows:

public class MyService : IService
{
    //Whatever Methods
}

Then on application startup you would obviously load all of your services into the service locator:

MyService myService = new MyService(...);
//...do whatever you need to setup the service

ServiceLocator<MyService>.Load(myService);

So later on anywhere in your code you simply do a

MyService myService = ServiceLocator<MyService>.Get();

It's pretty simple but just in case...As you can see I chose to use the FullName of the type as the key in map, you could always choose to do it the way Martin Fowler did where you simply expose the instance of each service type directly but for me I kind of liked this method.

Been working on a new application called VistaTune, it is open on CodePlex so you should go check it out but basically its an application that will enable you to tune Vista as well as setup profiles to use for certain "modes" such as gaming, developing, etc.  In any case during my development I noticed that the ServiceController class of .NET is lacking in that it does not allow you to change the Startup Mode of a service.  Personally I find this kind of odd since it lets you do everything else, so I went ahead and wrote an Extension Method for this class.

The below code is the cleanest and quickest implementation I could come up with, note that editing the registry to change the behavior of a service is considered evil and is very problematic so I would not recommend that route.

        public static void ChangeStartMode(this ServiceController sc, ServiceStartMode mode)
        {
            ManagementPath managementPath = new ManagementPath()
            {
                Server = System.Environment.MachineName,
                NamespacePath = ManagementPath.DefaultPath.NamespacePath,
                RelativePath = String.Format("Win32_Service.Name='{0}'", sc.ServiceName)
            };

            //Method: ChangeStartMode, Parameters: Mode (string), Return Value: int (0 success)
            new ManagementObject(managementPath).InvokeMethod("ChangeStartMode", new object[] { mode.ToString() });
        }

I hope this helps anyone that is having this problem, I did not find very good solutions to this problem when I was searching for it.  Also most of the code samples I found were very dirty, created lots of objects that were not necessary, etc.

If you bind a property to a UI element and then changed the value of that property on the back end entity the UI will not reflect that change unless you update the UI manually right?  Well no, not entirely true, and in my case I am going to speak WPF because I do not know if this is available in WinForms since I never used it in WinForms.

Let's say for example you have a ListView control that is bound to "Balance" for all 45 items, let say you have a background thread that is processing and is going through the records and updating this value.  How nice would it be for the UI to automatically update when this happen?  Well it's easily doable since binding automatically supports this functionality.

All you have to do is implement the INotifyPropertyChanged interface on your entity, after which you will get a new event.  Then in the method or property setter you fire this event, the UI will be watching for it and it will automatically fetch the new value for the value you specified.  This should also be faster since you don't need to update the entire binding context of the control.

Simply call PropertyChanged(this, new PropertyChangedEventArgs("Balance")) and only the specified property will update.

Was messing with the ListView control in WPF as usual and could not for the life of me figure out how to get the Image source attribute (Image is a separate control type) to show the image of a bitmap that I pulled from an icon from the system.  Basically what I was doing was I was using SHGetFileInfo to retrieve the icon of a particular file, I have two columns in my ListView.  The first column holds a <Image> element the second column holds a <TextBlock> element which displays the path.  I wanted the first column to display the system icon of the second column, so I retrieved this value through the windows API SHGetFileInfo (unmanaged) and got back an Icon which I then convert to a Bitmap.  I wrote a helper utility that does all of this, it also caches the images for common file extensions to prevent excessive system fetching. 

But setting the source in XAML to the property of type Bitmap does nothing, it turns out you have to set the source to the path of the image.  Well my question was, how do you specify the path of an image that you have in memory?  Also then how do you specify the path to XAML?  Well it turns out you can write something called a Converter that will convert the value of anything you want before the binding actually takes place.  Using the following XAML syntax to setup the binding, there are two steps, first you setup the local resource, second you specify the converter to use.

Resource:

   1:  <Window.Resources>

   2:      <custom:ImageConverter x:Key="imageConverter" />

   3:  </Window.Resources>

Binding Syntax:

<Image Source="{Binding Path=Image, Converter={StaticResource imageConverter}}" ... >

Next you must write the converter, since the convert I am using is read only the ConvertBack method does nothing.  There does not appear to be a read-only version of this interface so this is the best I could think of, in any case it works.  There is another interface called IMultiValueConverter, from what I gather it converts an array of objects handed to it.

The convert I wrote that takes a Bitmap and returns the source path:

   1:  [ValueConversion(typeof(Bitmap), typeof(string))]

   2:      public class ImageConverter : IValueConverter

   3:      {

   4:          public object Convert(object value, Type targetType, object parameter, System.Globalization.CultureInfo culture)

   5:          {

   6:              return Imaging.CreateBitmapSourceFromHBitmap(((Bitmap)value).GetHbitmap(), IntPtr.Zero, Int32Rect.Empty,

   7:                  BitmapSizeOptions.FromEmptyOptions());

   8:          }

   9:   

  10:          public object ConvertBack(object value, Type targetType, object parameter, System.Globalization.CultureInfo culture)

  11:          {

  12:              return null;

  13:          }

It returns a BitmapSource which it turns out is one of the types that you can bind to with the Image Source attribute in XAML, so this works.  So first off you do not want to use this for Resource files, you should use the built in WPF support such as setting the path to its package location:

"pack://application:,,/Resources/file.ico"

Which will work as long as you don't set the location of the resource to "Embedded Resource" since that is not supported.  If you need to store vector based graphics you can use the Resource Management support of WPF but if you can't for valid reasons than the above option seems to be your only one.

In a previous post I mentioned I couldn't figure out how to get a column to stretch the width of the control when it was expanded.  Well I stumbled onto a binding feature that is very very cool, its called RelativeSource and it lets you bind to properties on the control itself using the Self attribute, or the one I care about is child controls.

So in all its glory, the code that I use to set to an arbitrary number, is now set to a number that auto increments when the controls width is changed which you can verify by placing it in a text block.

   1:  Width="{Binding RelativeSource={RelativeSource AncestorType={x:Type ItemsControl}, AncestorLevel=1}, Path=ActualWidth}"

So yes it is verbose, and yes at first glance its confusing but it makes sense when you understand what its doing.  It's just going one level down to its container, and then I am getting the ActualWidth of that container.  Why not width?  Well I don't set the width on that control so the width will be null actually, in WPF width does not give you the Width of the control.  Instead it gives you the width that you have set it to if ever, and ActualWidth gives you the current active width of the control.

Today has been a HUGE WPF day for me, I have spent the entire day working with it and its exciting.  I hope to share all my findings with everyone that needs it.  It is very difficult to find information on how to do a lot of the stuff I am posting about, most of it has taken me hours upon hours of trial and error to get it working.

In WPF the beloved and well known InvokeRequired method has disappeared from the framework.  Replacing it is the Dispatcher, and it's methods CheckAccess and VerifyAccess pretty much are the replacement for InvokeRequired.

So if you have done any new WPF work you will quickly think, what the hell am I talking about.  Because if you type Dispatcher and wait for intellisense you don't see these methods, well that's because they are explicitly hidden from intellisense.  One can assume they did this intentionally to prevent developers from overusing these methods, since every WPF object will periodically call these methods on their own it's not necessary for you to check manually.  Unless you are developing your own WPF object, at least that's my best guess.

They have actually marked the Dispatcher.CheckAccess and Dispatcher.VerifyAccess with the [EditorBrowsable(EditorBrowsableState.Never)] (thanks Karsten Januszewski)attribute so you can see that they are intentionally hiding this from view.  I hope more light is shed on this topic as it's quit confusing.  Also there is a hack circulating for a way to check if the executing thread needs to be marshalled or not by doing a comparison against the UI thread.  To me that code really makes me feel dirty just by looking at it.

So how do you use the Dispatcher?  Well there are numerous different ways, I prefer to use an anonymous delegate:

   1:   Dispatcher.BeginInvoke(DispatcherPriority.Normal, (ThreadStart)delegate

   2:  {

   3:    //Update UI 

   4:  });

You don't have to use the ThreadStart delegate, the reason I use it is simply because it takes no parameters.  You can also obviously point it at a method, or itself which if you do that you will need to use CheckAccess in that instance.  There is a very valid performance reasons controls don't check to see if they are on the correct thread every single time.  If you do it the second way you incur that overhead, so out of curiosity I ran a benchmark comparing the two styles.

In the first benchmark I used the method above, and got the following results (in milliseconds):

Algorithm used for benchmark (simulates a real world data event, think of the DataGrid):

   1:  ArrayList al = new ArrayList();

   2:  for (int i = 0; i < 100000; i++)

   3:  {

   4:    al.Add("Test");

   5:    if (NewItem != null)

   6:      NewItem(this, EventArgs.Empty);

   7:  }

Is this a 100% solid benchmark? Probably not, in fact someone else might be able to get differing results but it does show a difference which is really quit obvious.  You are calling an additional method so you would expect it to take slightly longer but it also illustrates why they don't call this on the WPF object for every single method call natively.