SADev

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.

A long time ago I built a simple Excel spread sheet which worked out if an ID number was valid or not. Since then I have had a bunch of feedback on it, most about how it works. However a week ago Riaan contacted me and pointed out a bug in it so I took this as an opportunity to rebuild it.

Not only does the new version check the validity of the ID number, it tells you where the person was born, gender and birthdate.

Something else that I wanted to do was clean up the calculations. So now they have been moved to their own (non-hidden) tab and are fully documented. So if you are implementing your own checker you can clearly see exactly what is going on and how it all comes together.

Finally for those who wish to do a lot of checking, the third sheet of the Excel spread sheet contains that functionality where the checks are inline so that you can apply them to multiple ID numbers.

I want to extend a massive thanks to Riaan Pretorius, not only for pointing out the bug but also running the new version through it’s paces and finding some issues in it. The fact this one is much better is owed to him, I just typed the code

You can download the Excel file below!

If you follow the IW website you may have seen that the September community meeting in Jo’burg would be about SharePoint 2010 Deployments. That has changed to something far more exciting: Double Demo Day!

Double Demo Day means we get to see two members of the community do a demo of something very interesting.The demos are:

Creating Workflows with SharePoint Designer 2010, InfoPath and Visio

Creating workflows with Visio 2010 and SharePoint Designer 2010 has never been easier. In this session I’ll go through the process of rapidly creating and deploying workflows in a SharePoint 2010 environment.

This will be presented by Ridwan Sassman, who helped us out last month with video taping the session.

Branding SharePoint 2010 with MasterPages, Layouts and CSS

One of the largest limitations of WSS3.0 and MOSS2007 is the ability to brand SharePoint without intricate knowledge of the platform and in some cases breaking a few rules and modifying out of the box system files to get the desired look and feel. Come and see how the theming engine in SharePoint 2010 together with CSS, Master Pages and Layouts can be used to brand your SharePoint site using the amazing new SharePoint Designer 2010.

This will be presented by Brent Samodien. If you have been to a SLAB’s you will know Brent as he helps us with the venue!

October

Looking ahead to October – there is no Jo’burg community meeting. Why? ‘cause we will all be at Tech·Ed Africa 2010! If you haven’t registered then you must do so NOW! Or you could try and win a free entry!

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.