• Notes on Using Various PCL Profiles with Xamarin posted on 16 Apr 2014

    Below are some notes that I took today while researching various PCL profiles and their compatibility for use with Xamarin in Visual Studio. It's by no means complete, and the known limitations for Xamarin.Android and Xamarin.iOS apply in addition to what I noted below.

    Profile 151 (.NET 4.5.1, Windows 8.1, Windows Phone 8.1)

    • Doesn't work yet with the tooling (even with the SupportedFramework Fix)
      • Requires updated façade assemblies for MonoDroid & MonoTouch as well as the SupportedFramework targets
      • Likely to be supported in the future
    • This is a slightly updated version of Profile 111
      • Several assemblies updated to newer versions
        • System.Diagnostics.Tracing
        • System.Runtime
        • System.Runtime.InteropServices
      • Access to System.Threading.Timer which isn’t available in Profile 111
    • Most current and forward looking profile (at the expense of compatibility)

    Profile 111 (.NET 4.5, Windows 8.0, Windows Phone 8.1)

    • Works after using the SupportedFramework Fix
    • No WCF (Due to WP8.1 support)
    • Access to (but not available in profiles 259, 344, 78, or 158):
      • Parallel Tasks
      • Parallel LINQ
      • Concurrent Collections
      • System.Net.Http
      • System.Numerics
      • System.IO.Compression
        • This doesn't appear to be implemented yet in Xamarin

    Profile 259 (.NET 4.5, Windows 8.0, Windows Phone Silverlight 8.0, Windows Phone 8.1)

    • Works after using the SupportedFramework Fix
    • Very good Xamarin compatibility
    • Basically replaces Profile 78
    • No WCF (Due to WP8.1 support)

    Profile 344 (.NET 4.5, Windows 8.0, Windows Phone Silverlight 8.0, Silverlight 5, Windows Phone 8.1)

    • Works after using the SupportedFramework Fix
    • Basically replaces profile 158
    • Very good Xamarin compatibility
    • Broadest Reach (most platforms) of the .NET 4.5+ Profiles
    • No WCF (Due to WP8.1 support)
    • Async/Await requires use of a NuGet package (Due to SL5 support)

    Profile 78 (.NET 4.5, Windows 8.0, Windows Phone Silverlight 8.0)

    • Works out of the box
    • Very good Xamarin compatibility
    • This is Xamarin's current preferred profile, but that will likely change to 259 in the future

    Profile 158 (.NET 4.5, Windows 8.0, Windows Phone Silverlight 8.0, Silverlight 5)

    • Works out of the box
    • Very good Xamarin compatibility
    • Broad reach
    • Async/Await requires use of a NuGet package (Due to SL5 support)
  • Fix for Creating PCLs in Visual Studio That Target Windows Phone 8.1 and Xamarin posted on 10 Apr 2014

    Trouble in Paradise

    With BUILD over and the Visual Studio Update 2 RC released, many of us are playing with the new Windows Phone 8.1 bits.

    However, if you're using Xamarin in Visual Studio and you've tried to create a new (or update an existing) Portable Class Library that targets both the new Windows Phone 8.1 application type and Xamarin iOS/Android, you may have encountered a problem:

    Visual Studio PCL Error

    At this moment, Xamarin is aware of the issue and a fix will be coming in an updated release of the Xamarin tools for Visual Studio, but if you're impatient like me and want/need to use the bits RIGHT NOW, there is in fact a workaround...

    A New Hope

    So what do we need to do? Turns out the workaround is pretty straight forward.

    Open up the C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETPortable\v4.5\Profile\Profile78\SupportedFrameworks folder (changing the drive letter accordingly) and select Xamarin.Android.xml and Xamarin.iOS.xml.

    Supported Framework Files Source

    If you only have Xamarin for iOS or Xamarin for Android installed, you may only see one of these 2 files and that's perfectly fine.

    Now we're going to copy the file(s) to C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETPortable\v4.5\Profile\Profile259\SupportedFrameworks. You may be prompted for administrator rights to do this, just click ok.

    Supported Framework Files Source

    So, why did we choose Profile 259 anyway?

    Well, prior to Visual Studio 2013 Update 2, Xamarin's best supported (and favorite) profile was PCL profile 78.

    PCL Profile 259 is Profile 78 + Windows Phone 8.1 (and the "new profile 78") which should give us the highest amount of compatibility.

    At this point close Visual Studio (if it was still open) and then launch it again.

    Now if we select .NET Framework 4.5, Windows 8, Windows Phone Silverlight 8, Windows Phone 8.1, Xamarin.Android, and/or Xamarin.iOS everything should work...

    Supported Framework Files Source

    Supported Framework Files Source

    Epilogue

    If you can't use Profile 259 because you need to support different platform targets, this fix works for other profile numbers as well, though Xamarin compatibility may be dimished as the PCL Profile may support some functionality that one or more of the Xamarin platforms can't (ex. dynamic).

    A good example would be if you also needed to target Silverlight 5. You would copy the two xml files into the .NETPortable\v4.0\Profile\Profile344 folder (This is also a very good profile for Xamarin development).

    Credits

    This fix comes courtesy of Oren Novotny, so if it helps you, be sure to thank (and follow) him!

  • Announcing XamarinAppDev.com and @XamarinAppDev posted on 28 Feb 2014

    Some of you may have noticed that I silently launched a new link blog and Twitter account on Monday. Today I'm formally announcing both: Say hello to http://XamarinAppDev.com and @XamarinAppDev!

    XamarinAppDev on Twitter

    I've been working on a very large native cross platform application for a client that runs on iOS, Android, Windows Phone, and Windows Store, leveraging the Xamarin tools. A natural extension of that process has been searching for news and content about what is going on in the Xamarin developer community.

    So following in the footsteps of http://WindowsAppDev.com and @WindowsAppDev, my hope is that the new site and and Twitter feed will be a valuable resource for the Xamarin community.

    And fear not, I won't be neglecting my Windows developer readership. My family, maybe, but not you dear developer community. (:

  • Enabling NuGet Support in Xamarin Studio posted on 27 Feb 2014

    Previously we looked how to configure Xamarin Studio to feel a bit more familiar to those of us coming from Visual Studio. Now we're going to take a look at how to install the NuGet package manager Add-in for Xamarin Studio.

    NuGet

    Adding the NuGet Add-in isn't difficult, but there are a number of steps involved.

    Open the Tools menu, then click on Add-in Manager. On OSX you can find this option under the Xamarin Studio menu.

    NuGet for Xamarin Studio Step 1

    Select the Gallery tab, open the Repository drop down menu, sand and select Manage Repositories...

    NuGet for Xamarin Studio Step 1

    Click on the Add button in the Add-in Repository Management window.

    NuGet for Xamarin Studio Step 1

    On the Add New Repository window, select Register an on-line repository, enter http://mrward.github.com/monodevelop-nuget-addin-repository/4.0/main.mrep for the url, and click OK.

    NuGet for Xamarin Studio Step 1

    Back on the Add-in Repository Management window, we're going to open the IDE extensions node in the left panel, select NuGet Package Management, and click on the Install buttton located at the bottom of the right panel.

    NuGet for Xamarin Studio Step 1

    This is going to open a prompt asking us the confirm the installation of the Add-in. Click on Install in the dialog, then go ahead and click on the Close button on the Add-in Repository Management window.

    NuGet for Xamarin Studio Step 1

    Bask in our freshly installed NuGet-y goodness. You'll find two new menu options when you right click on a Solution, Project, or Project References node in the Solution Pad (the different tool windows in Xamarin Studio are called Pads): Manage NuGet Packages... and Restore NuGet Packages.

    NuGet for Xamarin Studio Step 1

    A big thanks to Matt Ward for creating the MonoDevelop/Xamarin Studio NuGet Add-in. Head over to the MonoDevelop NuGet Add-in project site on GitHub to learn even more about using the Add-in.

  • Xamarin Studio Settings for Visual Studio Developers posted on 26 Feb 2014

    If you are like me, a Visual Studio developer just getting started with Xamarin Studio, this new environment can seem a bit alien. Here's a couple of quick settings you can change to make yourself feel much more at home in the Xamarin IDE.

    The instructions below are for Xamarin Studio running on Windows, but if you are using Xamarin Studio on OSX, just open Xamarin Studio, Preferences whenever you see Tools, Options in the steps.

    Code Folding

    Under Tools, Options, then Text Editor, select General. On this screen, you can just tick the box for Enable code folding, and you're all set.

    Optionally, you can also tell Xamarin Studio whether it should collapse by default code #regions and code comments in the editor.

    Code Folding Options in Xamarin Studio

    Syntax Highlighting

    Also under Tools, Options, and Text Editor, you'll find the Syntax Highlighting settings. Here you can tell Xamarin Studio to use a syntax highlighting theme that closely resembles the one used by Visual Studio.

    Visual Studio Colored Syntax Highlighting in Xamarin Studio

    Key Bindings

    Under Tools, Options, then Environment, you'll find the Key Bindings settings. Here you can change the key binding scheme to match Visual Studio. This scheme appears to only be available in the Windows version of Xamarin Studio.

    Visual Studio Key Bindings in Xamarin Studio

    In my copy of Xamarin Studio (I'm using the Alpha channel), this key binding scheme has a conflict with Control + . being bound to two different commands. I resolved this by changing the quick fix command to use Alt + Enter which should be familiar to ReSharper users.

    Source Analysis

    This last one is less of a Visual Studio familiarity issue per se, but rather for those of us who might be missing ReSharper in this new IDE. Under Tools, Options, then Text Editor, you'll find the Source Analysis settings. Turn this on to get real-time feedback in the code editor about the your code, similar to RS.

    Xamarin Studio Source Analysis

    These settings go a long way toward mitigating the friction of moving between Visual Studio and Xamarin Studio.

    Maybe once I'm more familiar moving around inside Xamarin's IDE, I will consider changing the key bindings and syntax highlighting back to their defaults. Or not... (:

  • Announcing WindowsAppDev.com (and other site updates) posted on 17 Feb 2014

    Site Changes

    If you're visiting my site right now you may have noticed a new theme and a snappier response time.

    Also, you may have noticed that the Windows App Developer Links posts are not immediately visible. Fear not, for they have finally been given the respect they truly deserve and now have their very own site at WindowsAppDev.com!

    What this does mean though, is if you are subscribed to my blog feed (and you are subscribed, right?), if you want to continue to receive my (almost) daily Windows App Developer Links, you'll need to subscribe to the new feed.

    Technical Details

    This new blog is created using Sandra.Snow and the Sandra.Snow.Template. I was previously using WordPress and while it made life simple, I'm not a PHP guy and making tweaks to the site was a bit painful.

    This blog (and WindowsAppDev.com) are now running on a new VPS in Los Angeles. While I love my old host, the performance of running WordPress in a shared hosting environment wasn't great and wasn't getting better over time.

    Both sites are setup to use a git repository that I push to the VPS over ssh and then a post receive hook on the server uses rsync to copy the changed files to the their respective webserver folder and fixes their file permissions.

    So what this should mean for me is my site is much more portable (I can literally just copy a bunch of files to a new web server), more fault tolerant (I have multiple copies of the website source), and more secure (there's no CMS to break into, it's just static files).

    What this should mean for you, is the site is much faster, a bit more mobile friendly, and you can choose what you want to see in terms of my content posts and my Windows App Developer Links posts. Choice is a good thing. ☺

  • Announcing the @Win8DevNews Twitter Account posted on 24 Sep 2012

    Twitter Logo

    If you've been following me on Twitter recently, you may have noticed me mention the @Win8DevNews Twitter account.

    Today I'd like to take the opportunity to formally announce that I've teamed up with Michael Crump (of Telerik fame) to provide a Twitter feed of all the latest news and links relevant to Windows 8 app developers.

    If you're a current RSS subscriber or daily visitor to my Windows 8 Developer links blog, then this Twitter account will provide a new way of getting the same great curated Windows 8 Developer links.

    Head on over to Twitter and follow Win8DevNews (@Win8DevNews) to join in.

    Be sure to follow me (@DanRigby) and Michael (@MbCrump) while you're there.

    A great many thanks goes out to Michael who registered the Win8DevNews Twitter handle and the Win8DevNews.com domain a while back and decided to reach out to me about putting them to good use for the Windows 8 Developer community.

    Michael has also posted a great write-up on his blog about Win8DevNews, so be sure to check it out!

  • Windows 8 Dev Tip: Nullable<T> Dependency Properties and Binding posted on 24 Jul 2012

    Author's Note: If you're here just for a solution and are not interested in the extraneous bits, feel free to jump to the workaround details.

    First, some background...

    Let's say you're building a user control and one of your control's properties needs to be a three state boolean (true, false, null).

    No sweat, we'll just create a nullable boolean (bool?) dependency property:

    public static readonly DependencyProperty ValueProperty =
        DependencyProperty.Register("Value",
            typeof(bool?),
            typeof(TestControl),
            new PropertyMetadata(null));
    

    Ok, now that we have that taken care of, we want the user control to display different colors based on the value of the Value property.

    So let's add logic to handle the onchange callback of the dependency property:

    public static readonly DependencyProperty ValueProperty =
        DependencyProperty.Register("Value",
            typeof(bool?),
            typeof(TestControl),
            new PropertyMetadata(null, ValueChanged));
    
    private static void ValueChanged(DependencyObject sender, DependencyPropertyChangedEventArgs args) {
        ((TestControl)sender).ValueChanged();
    }
    
    private void ValueChanged() {
        bool? value = this.Value;
        if (!value.HasValue) {
            this.grid.Background = new SolidColorBrush(Colors.Blue);
        }
        else if (value.Value) {
            this.grid.Background = new SolidColorBrush(Colors.Green);
        }
        else {
            this.grid.Background = new SolidColorBrush(Colors.Red);
        }
    }
    

    Doing good, now lets piece it all together by adding a main page, binding our new user control to the page's datacontext, and creating a few radio buttons to change the value of the datacontext:

    TestControl.xaml:
    <UserControl x:Class="NullableBoolBinding.TestControl"
                 xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
                 xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
        <Grid Name="grid" Background="Blue"/>
    </UserControl>
    
    TestControl.xaml.cs:
    using Windows.UI;
    using Windows.UI.Xaml;
    using Windows.UI.Xaml.Controls;
    using Windows.UI.Xaml.Media;
    
    namespace NullableBoolBinding
    {
        public sealed partial class TestControl : UserControl
        {
            public static readonly DependencyProperty ValueProperty =
                DependencyProperty.Register("Value",
                    typeof(bool?),
                    typeof(TestControl),
                    new PropertyMetadata(null, ValueChanged));
    
            public bool? Value {
                get { return (bool?)this.GetValue(ValueProperty); }
                set { this.SetValue(ValueProperty, value); }
            }
    
            public TestControl() {
                this.InitializeComponent();
            }
    
            private static void ValueChanged(DependencyObject sender, DependencyPropertyChangedEventArgs args) {
                ((TestControl)sender).ValueChanged();
            }
    
            private void ValueChanged() {
                bool? value = this.Value;
                if (!value.HasValue) {
                    this.grid.Background = new SolidColorBrush(Colors.Blue);
                }
                else if (value.Value) {
                    this.grid.Background = new SolidColorBrush(Colors.Green);
                }
                else {
                    this.grid.Background = new SolidColorBrush(Colors.Red);
                }
            }
        }
    }
    
    MainPage.xaml:
    <Page x:Class="NullableBoolBinding.MainPage"
          IsTabStop="false"
          xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
          xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
          xmlns:local="using:NullableBoolBinding">
    
        <Grid Background="{StaticResource ApplicationPageBackgroundThemeBrush}">
            <Grid.RowDefinitions>
                <RowDefinition Height="*"/>
                <RowDefinition Height="Auto"/>
            </Grid.RowDefinitions>
    
            <local:TestControl Value="{Binding}"/>
    
            <StackPanel Orientation="Horizontal"
                        HorizontalAlignment="Center"
                        Grid.Row="1">
                <RadioButton Content="True"
                             Checked="TrueRadioButtonChecked"
                             Margin="10"/>
                <RadioButton Content="False"
                             Checked="FalseRadioButtonChecked"
                             Margin="10"/>
                <RadioButton Content="Null"
                             Checked="NullRadioButtonChecked"
                             Margin="10"/>
            </StackPanel>
        </Grid>
    </Page>
    
    MainPage.xaml.cs:
    using Windows.UI.Xaml;
    using Windows.UI.Xaml.Controls;
    using Windows.UI.Xaml.Navigation;
    
    namespace NullableBoolBinding
    {
        public sealed partial class MainPage : Page
        {
            public MainPage() {
                this.InitializeComponent();
            }
    
            protected override void OnNavigatedTo(NavigationEventArgs e) {
                this.DataContext = null;
            }
    
            private void TrueRadioButtonChecked(object sender, RoutedEventArgs e) {
                this.DataContext = true;
            }
    
            private void FalseRadioButtonChecked(object sender, RoutedEventArgs e) {
                this.DataContext = false;
            }
    
            private void NullRadioButtonChecked(object sender, RoutedEventArgs e) {
                this.DataContext = null;
            }
        }
    }
    

    Ok, we're done, so let's fire up our new app and test it out!

    Binding Failure

    Wait a second... the null value works, but when you select true or false nothing changes. What gives?

    Glancing at our output window while we have the debugger attached gives us this piece of information:

    Error: Converter failed to convert value of type 'Windows.Foundation.IReference`1<Boolean>' to type 'IReference`1<Boolean>'; BindingExpression: Path='' DataItem='Windows.Foundation.IReference`1<Boolean>'; target element is 'NullableBoolBinding.TestControl' (Name='null'); target property is 'Value' (type 'IReference`1<Boolean>').
    

    Ok then, what the heck is a IReference`1 and why are we trying to convert it?

    Turns out that under the covers most of the .NET primitive types are converted to equivalent Windows Runtime types. IReference happens to be the Windows Runtime equivalent of Nullable in .NET. In fact, Jeremy Likness has a good blog post WinRT/.NET type conversion that I'd recommend taking a look at.

    So right about now you're thinking, "Great, thanks for the technological archaeology lesson, but that doesn't explain why it's not working or what I need to do to fix it..."

    So, despite some considerable effort in researching the issue (and finding a WinRT dev forum post saying that nullable dependency properties in custom user controls are not supported), I couldn't find any explanation as to why this fails, but it turns out there is a workaround...

    And the answer is...

    Change the dependency property type to object. So, in our example, we change:

    public static readonly DependencyProperty ValueProperty =
        DependencyProperty.Register("Value",
            typeof(bool?),
            typeof(TestControl),
            new PropertyMetadata(null, ValueChanged));
    

    to:

    public static readonly DependencyProperty ValueProperty =
        DependencyProperty.Register("Value",
            typeof(object),
            typeof(TestControl),
            new PropertyMetadata(null, ValueChanged));
    

    That's it. At this point everything just starts working as expected. You don't even have to change your instance property type.

    Binding Success

    It's a shame reflection doesn't work on the WinRT XAML controls since they're written in native code, because I'd love to see how the ToggleButton.IsChecked property is implemented...

  • Windows 8 Dev Tip: Animating Attached Properties posted on 18 Jul 2012

    When you're working with Metro Style apps, eventually you'll want to animate an attached property. A common example is changing which grid row or column an element is in when reacting to a layout change.

    Let's give it a try:

    <VisualStateManager.VisualStateGroups>
        <VisualStateGroup x:Name="ApplicationViewStates">
            <VisualState x:Name="FullScreenLandscape" />
            <VisualState x:Name="Filled" />
            <VisualState x:Name="FullScreenPortrait" />
            <VisualState x:Name="Snapped">
                <Storyboard>
                    <ObjectAnimationUsingKeyFrames Storyboard.TargetName="gridItem"
                                                   Storyboard.TargetProperty="Grid.Column">
                        <DiscreteObjectKeyFrame KeyTime="0"
                                                Value="0" />
                    </ObjectAnimationUsingKeyFrames>
                </Storyboard>
            </VisualState>
        </VisualStateGroup>
    </VisualStateManager.VisualStateGroups>
    

    Oops! That didn't work:

    Error

    So what's the secret sauce for Attached Properties? Parentheses.

    So let's try again:

    <VisualStateManager.VisualStateGroups>
        <VisualStateGroup x:Name="ApplicationViewStates">
            <VisualState x:Name="FullScreenLandscape" />
            <VisualState x:Name="Filled" />
            <VisualState x:Name="FullScreenPortrait" />
            <VisualState x:Name="Snapped">
                <Storyboard>
                    <ObjectAnimationUsingKeyFrames Storyboard.TargetName="gridItem"
                                                   Storyboard.TargetProperty="(Grid.Column)">
                        <DiscreteObjectKeyFrame KeyTime="0"
                                                Value="0" />
                    </ObjectAnimationUsingKeyFrames>
                </Storyboard>
            </VisualState>
        </VisualStateGroup>
    </VisualStateManager.VisualStateGroups>
    

    No more errors!

  • INotifyPropertyChanged, The .NET 4.5 Way - Revisited posted on 01 Apr 2012

    In what is what is becoming a never ending topic on my blog, I have stumbled across yet another interesting implementation of INotifyPropertyChanged.

    This implementation comes to us via the C# / XAML Windows 8 Metro application project templates in the Visual Studio 11 beta. In the project templates we are given a base class which implements INotifyPropertyChanged, BindableBase.

    Here is the class in it's entirety:

    using System;
    using System.ComponentModel;
    using System.Runtime.CompilerServices;
    
    /// <summary>
    ///     Implementation of <see cref="INotifyPropertyChanged" /> to simplify models.
    /// </summary>
    [Windows.Foundation.Metadata.WebHostHidden]
    public abstract class BindableBase : INotifyPropertyChanged
    {
        /// <summary>
        ///     Multicast event for property change notifications.
        /// </summary>
        public event PropertyChangedEventHandler PropertyChanged;
    
        /// <summary>
        ///     Checks if a property already matches a desired value.  Sets the property and
        ///     notifies listeners only when necessary.
        /// </summary>
        /// <typeparam name="T">Type of the property.</typeparam>
        /// <param name="storage">Reference to a property with both getter and setter.</param>
        /// <param name="value">Desired value for the property.</param>
        /// <param name="propertyName">
        ///     Name of the property used to notify listeners.  This
        ///     value is optional and can be provided automatically when invoked from compilers that
        ///     support CallerMemberName.
        /// </param>
        /// <returns>
        ///     True if the value was changed, false if the existing value matched the
        ///     desired value.
        /// </returns>
        protected bool SetProperty<T>(ref T storage, T value, [CallerMemberName] String propertyName = null)
        {
            if (Equals(storage, value))
            {
                return false;
            }
    
            storage = value;
            this.OnPropertyChanged(propertyName);
            return true;
        }
    
        /// <summary>
        ///     Notifies listeners that a property value has changed.
        /// </summary>
        /// <param name="propertyName">
        ///     Name of the property used to notify listeners.  This
        ///     value is optional and can be provided automatically when invoked from compilers
        ///     that support <see cref="CallerMemberNameAttribute" />.
        /// </param>
        protected void OnPropertyChanged([CallerMemberName] string propertyName = null)
        {
            PropertyChangedEventHandler eventHandler = this.PropertyChanged;
            if (eventHandler != null)
            {
                eventHandler(this, new PropertyChangedEventArgs(propertyName));
            }
        }
    }
    

    This implementation, like my INotifyPropertyChanged, The .NET 4.5 Way post, uses the new CallerMemberName attribute in .NET 4.5. Where it differs though, is rather then using the EqualityComparer<T>.Default property to create a generic comparison, the code simply uses Object.Equals().

    I knew Object.Equals() checks to see if two objects have the same reference in order to determine equality. That seemed perfectly acceptable to me. But what about value types?

    Turns out, Object.Equals() handles those in a generic, but clever way:

    The default implementation of Equals supports reference equality for reference types, and bitwise equality for value types. Reference equality means the object references that are compared refer to the same object. Bitwise equality means the objects that are compared have the same binary representation.

    This is a lot less complicated (and most likely faster) then using EqualityComparer<T>.Default. There is, however, a subtle difference here in behaviour. Using EqualityComparer<T>.Default will do the following:

    The Default property checks whether type T implements the System.IEquatable(Of T) interface and, if so, returns an EqualityComparer(Of T) that uses that implementation. Otherwise, it returns an EqualityComparer(Of T) that uses the overrides of Object.Equals and Object.GetHashCode provided by T.

    So if you have custom equality comparisons implemented for some of your types, the EqualityComparer<T>.Default approach will most likely serve you better.

    The one other distinct difference this INotifyPropertyChanged implementation has over all of my previous examples, is that SetProperty<T>() returns true or false based on whether or not the value was updated. This can be very useful if you have more sophisticated property logic that needs to do more then just raise the event if value changes.

    All in all, I think I like this implementation the best.