.NET

Note: This is part of a series, you can find the rest of the parts in the series index.

Pull started as a learning exercise and so I didn’t feel bad about using a new technology for a component which may not be the best choice. IMPF was one such are where I decided to use a new technology, however it hasn’t been smooth sailing – but I persisted as it was important for me to learn.

I was working on some enhancements and bug fixes recently and I ended having to put yet another hack into IMPF to handle the technology behind the scenes. In this case a Thread.Sleep to have a partial delay between when things are written and when they are read. This was a wake up bell for me, because it felt dirty and stupid. So what did I do? I decided the best course of action was to step back and think what is the best way to do this – and so I ripped all the MemoryMappedFile file out and the Win32 API stuff (about 200 lines of code) and replaced it with a WCF service/client implementation.

To do that I needed the contract, which is about as simple as it can get:

[ServiceContract]
interface IDataService
{
    [OperationContract]
    void SendMessage(string message);
}

Next I needed the implementation, which is also very simple in a large part thanks to the bus.

class DataService : IDataService
{
    public void SendMessage(string message)
    {
        IBus bus = Factory.Instance.Resolve<IBus>();
    
        if (!string.IsNullOrWhiteSpace(message))
        {
            if (message[0] == '!')
            {
                switch (message)
                {
                    case "!playunplayed":
                        {
                            bus.Broadcast(DataAction.LaunchUnplayedEpisode);
                            break;
                        }
                    case "!forcerefresh":
                        {
                            bus.Broadcast(DataAction.UpdateFeeds);
                            break;
                        }
                }
            }
            else
            {
                // its a feed
                bus.Broadcast(DataAction.ParseFeed, message);
            }
        }
    }
}

You may note some command parameter items above, this is for new features I am working on.

Finally I needed a way to create the WCF service (the server) and a client to talk to it. I am using .NET 4 which means I get access to the great AddDefaultEndpoints method which makes this really simple. It figures out everything it needs for a default configuration from the URI that is passed. In my case I pass in a net.pipe URI so it sets up a named pipe for me.

public IPMF(string instance)
{
    host = new ServiceHost(typeof(DataService), new Uri(InstanceURL(instance)));
    host.AddDefaultEndpoints();
    host.Open();
}

Lastly sending a message to the named pipe is also very simple. You’ll note that I am using a ChannelFactory here and not an actual implementation. This is because I did not add a service reference, as the application has all the information it needs internally there is no need for additional code to be written.

public static void SendMessageToServer(string instance, string message)
{
    IDataService dataService = ChannelFactory<IDataService>.CreateChannel(new NetNamedPipeBinding(), new EndpointAddress(InstanceURL(instance)));
    dataService.SendMessage(message);
}

Final Thoughts

This is the correct way to do this, and it is what you should be using in real systems not only because it is so much less code but also because it works perfectly – no need to insane hacks.

My learning with IMPF was not only about the exceptionally powerful MemoryMappedFile in .NET 4 but also when it should and shouldn’t be used.

Saturday was Microsoft’s Dev4Dev’s event, where each presenter gets 20min to cover one topic. It is fantastic fun and a great way to learn.

For the event I decided to tackle CodedUI, which is just a great testing technology and in 20min I showed off a number of features using it. Below is the slides, which are not valuable - unless you jump to the hidden content where you find my demo script and some extra information!

If you are wanting to play with the demo’s you will also need my pre-constructed demo bits:

• The Xbox Super Store website: http://xbox360superstore.codeplex.com/
• My WPF application: Below
• The XML file with the values for the Data Driven test: Below

For those who attended and saw my second demo not go according to plan, I apologise again I’ve since run it again and it works every time, I guess the massive audience scared CodedUI into breaking

Note: This is part of a series, you can find the rest of the parts in the series index.

I’ve mentioned that a podcatcher is really just two things put together, a download manager and a feed parser. Feed parsing is not the easiest item to build, just look at my attempt many years ago to build a Delphi RSS parser called SimpleRSS – it works well, but there are many edge cases which can kill it.

The key things that trip you up when writing a parser is are:

• RSS and ATOM – There is two major formats for feeds, RSS and ATOM which are very different.
• Versioning – RSS and ATOM both have a number of versions which requires completely different parsing going on.
• Errors – It is easy to produce these, it’s just XML, and so there is a lot of feeds which do not validate.

With that in mind I am really happy that the .NET Framework (since 3.5), includes it’s own parser for feeds: SyndicationFeed.

SyndicationFeed

System.ServiceModel.SyndicationFeed supports both ATOM (version 1.0) and RSS (version 2.0) and to use it you need to add a reference to System.ServiceModel.dll. It only handles the parsing, and creation although I don’t care about that functionality in Pull, of feeds. To parse the feed you parse in a XmlReader to the Load method and it takes care of the parsing.

using (XmlReader reader = XmlReader.Create(podcastUrl))
{
    return SyndicationFeed.Load(reader);
}

That really is as complex as this gets

Note: This is part of a series, you can find the rest of the parts in the series index.

Pull for me is as much about learning as it is about writing a useful tool that others will enjoy and often I head down a path to learn it was wrong. Sometimes I realise before a commit and no one ever knows, other times it is committed and reading the source history is like an example of how bad things can get and sometimes I even ship bad ideas. IMPF is one such area where I shipped a huge mistake which caused Pull to easily consume an entire core of CPU for doing zero work.

IMPF would check for messages as using the following process:

 

The Thread.Sleep(0) is there to ensure application messages get processed, but it is zero so that as soon as a message arrives it is processed. This meant that the check, which did a lot of work, was running almost constantly. This means that Pull ended up eating 100% of a the power of a core

The Solution

The solution to this was to change the process from constantly checking to getting notified when there is a new message.

This is also much simpler to draw than the other way, maybe that should be a design check, the harder to draw the less chance it works

The only issue is how do I cause that trigger to fire from another application when it writes a message IMPF should read?

Windows Messaging

Windows internally has a full message system which you can use to send messages to various components in Windows, for example to turn the screen saver on or off, or to send messages to applications. I have used this previously in Pull to tell Windows to add the shield icon if needed (see Part IX) to the protocol handler buttons.

I can also use it to ping an application with a custom message which that application can act on. For Pull when I get that ping I know there is a new IMPF message.

The first part of this is finding the window handle of the primary instance that I want to ping. This I do by consulting the processes running on the machine and using a dash of LINQ filter it to the primary instance.

private static IntPtr GetWindowHandleForPreviousInstances()
{
    Process currentProcess = Process.GetCurrentProcess();
    string processName = currentProcess.ProcessName;

    List<Process> processes = new List<Process>(Process.GetProcessesByName(processName));
    IEnumerable<Process> matchedProcesses = from p in processes
                                            where (p.Id != currentProcess.Id) &&
                                            (p.ProcessName == processName)
                                            select p;

    if (matchedProcesses.Any())
    {
        return matchedProcesses.First().MainWindowHandle;
    }

    return IntPtr.Zero;
}

Now I know who to ping, I just need to send a ping. This is done by calling the Win32 API SendNotifyMessage:

public static int NotifyMessageID = 93956;

private static class NativeMethods
{
    [DllImport("user32.dll", SetLastError = true, CharSet = CharSet.Auto)]
    [return:MarshalAs(UnmanagedType.Bool)]
    public static extern bool SendNotifyMessage(IntPtr hWnd, int Msg, IntPtr wParam, IntPtr lParam);
}

public static void PingPreviousInstance()
{
    IntPtr otherInstance = GetWindowHandleForPreviousInstances();
    if (otherInstance != IntPtr.Zero)
    {
        NativeMethods.SendNotifyMessage(otherInstance, NotifyMessageID, IntPtr.Zero, IntPtr.Zero);
    }
}

That takes care of sending, but how do I receive the ping? I need to do is override the WndProc method on my main form to check for the message and if I get the right ID (see line 1 about – the NotifyMessageID) I then act on it. In my case I use the bus to tell IMPF that there is a new message.

protected override void WndProc(ref Message message)
{
    if (message.Msg == WinMessaging.NotifyMessageID)
    {
        this.bus.Broadcast(DataAction.CheckIPMF);
    }

    base.WndProc(ref message);
}

This has enabled IMPF to only act when needed, removed a thread (since it no longer needs it’s own thread), simplified the IMPF code and made Pull a better citizen on your machine.

Note: This is part of a series, you can find the rest of the parts in the series index.

Microsoft has offered a great tool called fxCop for a number of years now. This free tool takes your compiled .NET code and runs it against a number of rules to check things like security, compatibility, globalisation and so on.

Some of the higher SKU’s of Visual Studio have included fxCop directly in the IDE, via the Code Analysis option. In previous versions of Visual Studio this just ran the fxCop command line and returned the results. There was not much else happening except a shortcut to having to run a separate tool.

In Visual Studio 2010 the fxCop integration has had a major improvement, with the addition of a dedicated interface for the management of what rules are run and the ability for you to create a bespoke collection of the rules that you care about by ignoring the rules you do not care about. The other great feature is that you can set if a rule throws a warning or an error in Visual Studio. Very useful for enforcing rules!

For Pull, I took the opportunity to create a dedicated rule set.

Step One – Theft

The first thing I did was to take the Microsoft All Rules rule set and copy it to my project and rename it to pull.ruleset. You can find the Microsoft All Rule rule set file at: C:\Program Files (x86)\Microsoft Visual Studio 10.0\Team Tools\Static Analysis Tools\Rule Sets\AllRules.ruleset

Step Two – Minor Tweak

Next I opened the pull.ruleset file in a text editor (it is just XML) and changed the rule set name and description.

Step Three – Associate

Next I used the Browse option in the rule set selector to select my pull.ruleset file.

Step Four – Adjust Rules

Now I can use the Visual Studio rules editor (click the Open button) to adjust what rules I want to keep and what severity level I want them at. As I started with the Microsoft All Rules, I have all the rules listed initially and so this took a little bit of time to adjust.

Step Five – Source Control

Make sure you check in your custom rule set file so that everyone in the team can enjoy it’s powerful magic. If I was using a fully featured ALM tool (like TFS) and not just a source control tool, then I could also include the rules in my check-in policies which ensure that code that is checked in comply and also in my build server.

Note: This is part of a series, you can find the rest of the parts in the series index.

Windows Vista introduced a feature called User Account Control (UAC) which added the following to Windows (in addition to a lot of hair pulling by some users). Visually it brought a small shield overlay icon which indicates to the user that when you click that icon or button you will be prompted to confirm your action and possibly to enter an administrators username and password. This was introduced to stop people from shooting themselves in the foot by making certain actions which could break Windows require special privileges (called administrator privileges, which I find is confusing with administrator users and groups. So I call it root privileges).

I have been a fan of this idea since it was launched and as a developer I have kept it turned on, mainly because the my customers may not have it turned off. Imagine the scenario where I have it off and something works and on a customers machine it fails because UAC is on. I see a Works on my machine scenario coming up.

Pull has a part of it which actually bumps up against UAC – registering protocol handlers. I do not want the entire of Pull to need root privileges when running, I only want the small part where you can register or unregister a protocol handler to run in root privileges.

Multiple Processes

The first issue is that root privileges are given to an entire process, and you cannot give it to a thread or method or some sub part. To solve this for Pull, meant creating a second executable file named ProtocolHandler.exe, which takes a few command line parameters and handles the registering and unregistering of protocol handlers.

This enables Pull to launch this second executable with the required root privileges and have it do the dirty work without Pull needing any root privileges. 

Running with Root Privileges

Kicking off another process in C# is very easy thanks to the Process class which handles the launching with the Start method (line 11 below). The Process class knows which process to run thanks to the ProcessStartInfo class which is setup before hand and passed to the StartInfo property.

To enable root privileges in the new process all you need to do is set the Verb property of ProcessStartInfo to runas (line 6 below).

Something Pull wants is to wait for the process to finish running, so that the user is confused by it immediately returning and nothing has happened yet. This is solved by using the WaitForExit method on the Process (line 12 below).

private static void RunProtocolHandler(string arguments)
{
    ProcessStartInfo processStartInfo = new ProcessStartInfo();
    processStartInfo.FileName = Path.Combine(Directory.GetCurrentDirectory(), "ProtocolHandler.exe");
    processStartInfo.Arguments = arguments;
    processStartInfo.Verb = "runas";

    using (Process process = new Process())
    {
        process.StartInfo = processStartInfo;
        process.Start();
        process.WaitForExit();
    }
}

The Shield

The final component was to follow the UI guidelines and place a shield icon on the buttons which launch the other application, so that the user is aware this will require root privileges. While you can just grab a shield image and place it on the button that is not recommended because:

• What if the logo changes in future Windows versions? – you are out of date
• What if the shield is not needed, because the person is running with root privileges already?

To handle this for me I have a small class called UACShield which offers two methods:

• IsAdmin: this simple method returns true if you have root privileges and false if you don’t. This is done using pure .NET and just checking if the user has the Administrator role (line 14 below).
• AddShieldToButton: this method takes a button, and if a user is not an admin adds the shield icon. It does this by calling into the Win32 API and calling the SendMessage to update the button. One caveat of this is that the button’s flat style must match the system’s flat style. This means that if you have some special UI tweaks on the button this may break those tweaks.

internal class UACShield
{
    private class NativeMethods
    {
        [DllImport("user32")]
        public static extern UInt32 SendMessage(IntPtr hWnd, UInt32 msg, UInt32 wParam, UInt32 lParam);
        public const int BCM_SETSHIELD = 0x160C; //Elevated button
    }

    public static bool IsAdmin()
    {
        using (WindowsIdentity currentIdentity = WindowsIdentity.GetCurrent())
        {
            return new WindowsPrincipal(currentIdentity).IsInRole(WindowsBuiltInRole.Administrator);
        }
    }
                                                 
    public static void AddShieldToButton(Button button)
    {
        if (IsAdmin())
        {
            // no need for admins
            return;
        }

        button.FlatStyle = FlatStyle.System;
        NativeMethods.SendMessage(button.Handle, NativeMethods.BCM_SETSHIELD, 0, 0xFFFFFFFF);
    }
}

Note: This is part of a series, you can find the rest of the parts in the series index.

I’ve mentioned previously about Pull’s support for protocol handlers (see part 4) which enable the application to subscribe to a feed easily just by clicking a link. Today I will look at how I to register protocol handlers.

Protocol Handlers

Registering a protocol handler is one of the simplest things I did in Pull, because it is merely a registry key which needs to be added to the system. The registry key follows the pattern below.

Key

• blue = registry key
• orange = key/value setting

The important points (numbered above) are:

1. This is the protocol that you want to register, so if you want to register say zune:// then this is zune.
2. This is a useful description on the default key.
3. This is a setting named URL Protocol but the value must remain blank.
4. This is path to the icon. So for Pull I just use the default program icon by setting the value to: E:\PortableApps\Pull\Pull.exe,1
5. This is the command to execute when the URL is added. In Pull this is (note the %1 for the URL parameter): "E:\PortableApps\Pull\Pull.exe" "%1"

The code to do this is rather simple:

public static void Register(string executablePath, string uri)
{
    if (!OurProtocolHandler(uri))
    {
        return;
    }

    using (RegistryKey uriKey = Registry.ClassesRoot.CreateSubKey(uri, RegistryKeyPermissionCheck.ReadWriteSubTree, RegistryOptions.None))
    {
        uriKey.SetValue(string.Empty, Pull.Properties.Resources.PullPodcastURIHandler);
        uriKey.SetValue("URL Protocol", string.Empty, RegistryValueKind.String);
        using (RegistryKey iconKey = uriKey.CreateSubKey("DefaultIcon", RegistryKeyPermissionCheck.ReadWriteSubTree, RegistryOptions.None))
        {
            iconKey.SetValue(string.Empty, string.Format(CultureInfo.CurrentCulture, "{0},1", executablePath));
        }

        using (RegistryKey shellKey = uriKey.CreateSubKey("shell", RegistryKeyPermissionCheck.ReadWriteSubTree, RegistryOptions.None))
        {
            using (RegistryKey openKey = shellKey.CreateSubKey("open", RegistryKeyPermissionCheck.ReadWriteSubTree, RegistryOptions.None))
            {
                using (RegistryKey commandKey = openKey.CreateSubKey("command", RegistryKeyPermissionCheck.ReadWriteSubTree, RegistryOptions.None))
                {
                    commandKey.SetValue(string.Empty, string.Format(CultureInfo.CurrentCulture, "\"{0}\" \"%1\"", executablePath));
                }
            }
        }
    }
}

Being a good citizen

Pull is aware that some people may have other podcatchers installed, and to make sure I do not steal their protocol handlers I have a simple method, OurProtocolHandler, which checks if the protocol is in use and if a protocol is in use we do not override it.

private static bool OurProtocolHandler(string uri)
{
    using (RegistryKey uriKey = Registry.ClassesRoot.OpenSubKey(uri))
    {
        if (Registry.ClassesRoot.OpenSubKey(uri) != null)
        {
            return uriKey.GetValue(string.Empty).Equals(Pull.Properties.Resources.PullPodcastURIHandler);
        }
        else
        {
            return true;
        }
    }
}

Final Thoughts

This is one of the easiest parts to get working, however incorporating it in the application is not as simple which I will cover next.

Win 1 of 4 Tickets to Microsoft Tech·Ed Africa 2010 worth R6 150 each!!!

Venue:    ICC Durban

Date:       17th - 20th October 2010

All you need to do is take a photo of a Microsoft Tag in a really cool/funny/practical place and upload the picture to the Facebook competition page.

More details in the competition animated video here.

Full Competition Rules on our Facebook page.

Dates for Submissions & Announcements of Winners:

• 25 Aug 2010    -    Last Date For Submissions (week 1) (5pm)
• 27 Aug 2010    -    Week 1 Winner Announced
• 01 Sep 2010    -    Last Date For Submissions (week 2) (5pm)
• 03 Sep 2010    -    Week 2 Winner Announced
• 08 Sep 2010    -    Last Date For Submissions (week 3) (5pm)
• 10 Sep 2010    -    Week 3 Winner Announced
• 15 Sep 2010    -    Last Date For Submissions (week 4) (5pm)
• 17 Sep 2010    -    Week 4 Winner Announced

Submissions & Announcements of Winners:

• A new winner will be selected weekly.
• Last date for submissions for a particular week is 5pm Wednesday of that week.
• Winner for that week will be announced on the Friday.
• Submissions after 5pm will count towards the following week.
• Submissions which did not win in a previous week will still be considered in following weeks and need not be re-submitted.
• A person can only win once, thereafter all his other submissions will be ignored.
• You cannot submit on behalf of another person.
• Submissions are done by posting a photo to the Facebook page wall.

Terms and Conditions apply:

This competition is limited to Tech·Ed Africa 2010 entrance and does not include Travel, hotel or any other expenses. You will be required to help out at the Developers Community Lounge at Tech·Ed Africa 2010 for 3 hours a day if you do win. For Full list of rules please consult the Facebook page.

Note: This is part of a series, you can find the rest of the parts in the series index.

PLINQ, which is Parallel LINQ or the ability to run LINQ queries with parallel extensions in .NET 4. The idea is that you take a simple LINQ query and append .AsParallel on the end and it is magically parallel – as in my insane solution to Fizz Buzz below:

var result = from i in Enumerable.Range(0, 1000).AsParallel()
             where (i % 3 == 0 || i % 5 == 0)
             select new { value = i, answer = i % 3 == 0 ? i % 5 == 0 ? "Fizz Buzz" : "Buzz" : "Fizz" };

foreach (var item in result)
{
    Console.WriteLine("{0} gets a {1}", item.value, item.answer);
}

If you have been to one of my what’s new in .NET 4 talks you would’ve even seen me demo it this way, and for that I am VERY VERY SORRY – because I was wrong wrong wrong.

In Pull I used this exact mistake above to get the updating of podcasts to run in parallel and it wasn’t until I implemented some status view that I noticed it wasn’t actually in parallel (two weeks and 46 check-ins before I realised this).

The problem is that appending .AsParallel does nothing but some setup. To make use of parallel-ness you must use the .ForAll extension as in the example below (note the difference is in processing, note the query change on line 5):

var result = from i in Enumerable.Range(0, 30).AsParallel()
             where (i % 3 == 0 || i % 5 == 0)
             select new { value = i, answer = i % 3 == 0 ? i % 5 == 0 ? "Fizz Buzz" : "Buzz" : "Fizz" };

result.ForAll(item =>
{
    Console.WriteLine("{0} gets a {1}", item.value, item.answer);
});

Now Pull works all in parallel and I am happy to move on, right? WRONG again. In my research I found a white paper written by Pamela Vagata from the Parallel Computing Platform Group at Microsoft which covers when to use PLINQ and when to use Parallel.ForEach. This paper is fantastic and highlights that these are not equal and that you should use the right tool for the job. My quick reference table based on that white paper (the smile-y indicates what you should use):

Action	PLINQ	Parallel.ForEach
Simple Data-Parallel Operation with Independent Actions
Ordered Data-Parallel Operation
Streaming Data-Parallel Operation
Operating over Two Collections
Thread-Local State
Exiting from Operations

If you do not know what those actions mean then you must grab the white paper. As you can see for me I should never have used PLINQ because I am doing a Simple Data-Parallel Operation with Independent Actions. Why is PLINQ wrong, well the white paper explains:

While PLINQ has the ForAll operator, it may be easier to think in terms of parallel loops rather than parallel
queries for this type of scenario. Furthermore, PLINQ may be too heavyweight for a simple independent action.
With Parallel.ForEach, you can specify ParallelOptions.MaxDegreeOfParallelism, which specifies
that at most N threads are required. Thus, if the ThreadPool’s resources are scarce, even if the number of available
threads is less than N, those threads will begin assisting the execution of Parallel.ForEach. As more threads
become available, those resources will then be used for execution of the loop’s body delegate as well. However,
PLINQ requires exactly N threads, which is specified by using the WithDegreeOfParallelism() extension
method. In other words, for PLINQ N represents the number of threads which are actively involved in the PLINQ
query.

Final Thoughts

.NET 4 has made doing parallel very each, in fact it is too easy to do the wrong thing and still have it work. Spending time researching the right method is vital for software development, don’t just assume.

Stolen directly from Zayd Kara’s blog, which is a fantastic read. If you not reading his blog, you should.

Our team (editor: our = ATC team at BB&D) have been hard at work and are pleased to announce that following posters have been added to the DRP Site for FREE download. Here is a quick brief on the posters that have been added:

Direct Compute – “Microsoft DirectCompute is an application programming interface (API) that supports general-purpose computing on graphics processing units on Microsoft Windows Vista and Windows 7. DirectCompute is part of the Microsoft DirectX collection of APIs and was initially released with the DirectX 11 API but runs on both DirectX 10 and DirectX 11 graphics processing units”

Download and details.

WCF Error Handling Best Practices – WCF error handling is complicated by the fact that client and service are separated by physical boundaries. This quick reference poster provides you with best practices for handling WCF errors.

Download and details.

Windows Embedded Standard 2009 – “Windows Embedded is family of operating systems from  Microsoft designed for use in embedded systems.” This quick reference poster describes the development cycle of creating a Windows Embedded image.

Download and details.

Windows XP Mode & Windows Virtual PC - Windows XP Mode and Windows Virtual PC, available on Windows 7  allows you to run multiple Windows environments, such as Windows XP Mode, from your Windows 7 desktop. This quick reference poster provides you with a quick overview helping you decide if Windows XP Mode and Windows Virtual PC is for you.

Download and details.