.NET and me Coding dreams since 1998!

21Jan/120

What is new in WCF in .NET 4.5 – Task and async

.NET 4.5 WCF – unit testable out of the box

As I mentioned already in How to get testable WCF code in simplest way? problem with abstracting WCF services occur due to the fact that the service contract is by definition not containing the async members defined and every solution I’ve seen enabling asynchronous calls to a WCF service adds a certain level of complexity to the code base so therefore I have chosen to use service generated proxy enhanced with some T4 magic creating appropriate interfaces.

I am happy to report that is not true any more and that

WCF in .NET 4.5 enables VERY easy asynchronous service calls in a testable manner out of the box.

Here’s a source code of the simplest illustration of what is the point. Usual constraints: works-for-me and take-it-as-an-idea-only.

In case all this async, Task<T> C# 5.0 things are new for you I suggest checking out some of presentations from my TPL delicious stack (especially “Future Directions For C#…” one there)

Server side code

Let’s stick to the simplest possible sample of a vanilla WCF service having a single operation returning a server time

using System;
using System.ServiceModel;
using System.Threading.Tasks;

namespace WcfService1
{
    [ServiceContract]
    public interface ITestService
    {
        [OperationContract]
        Task<DateTime> GetServerTimeAsync();
    }
}

As you can notice there are two interesting moments in the contact definition:

  • Returning type is not DateTime - it is Task<DateTime>
  • The name of the operation ends with Async which is a naming convention for marking new C# 5.0 async methods

Implementation of the service contract is equally trivial:

using System;
using System.Threading.Tasks;

namespace WcfService1
{
    public class TestService : ITestService
    {
        public async Task<DateTime> GetServerTimeAsync()
        {
            return DateTime.Now;
        }
    }
}

Implementation has three key moments:

  • Method name ends with Async
  • It returns Task<DateTime>
  • method has a async keyword which allows me to write a simple method body like I would do it normally and return a simple date time and completely forget about Task<T>

In other words, thanks to C# 5.0 all I have to do is to replace DateTime with async task<DateTime> and everything else stays the same – AWESOME!.

Client side code

I am going to add to the solution simple console application and create a trivial service client file

using System;
using System.ServiceModel;
using System.Threading.Tasks;
using WcfService1;

namespace ConsoleApplication1
{
    public class TestServiceClient : ClientBase<ITestService>, ITestService
    {
        public Task<DateTime> GetServerTimeAsync()
        {
            return Channel.GetServerTimeAsync();
        }
    }
}

No magic here: using shared service library I get the service contract on client and use it in combination with ClientBase<T> to create a simple class wrapper implementing via delegation service contract.

Now the class which simulates the one performing a wcf service call in its implementation

using System;
using System.Threading.Tasks;
using WcfService1;

namespace ConsoleApplication1
{
    public class ServerTimeReader
    {
        private readonly ITestService testService;

        public ServerTimeReader(ITestService testService)
        {
            this.testService = testService;
        }

        public async Task<DateTime> GetTimeAsync()
        {
            return await this.testService.GetServerTimeAsync();
        }
    }
}

The ServerTimeReader has a ITestService based dependency injected through its constructor. It has a method called GetTimeAsync which awaits the async wcf service call to be finished. All the mumbo jumbo of AMP, events etc. in a single keyword – brilliant.

Now when we have a class invoking a WCF call let’s ramp up IoC container and make a async call to server using the code we wrote so far.

using System;
using Microsoft.Practices.Unity;
using WcfService1;

namespace ConsoleApplication1
{
    class Program
    {
        private static UnityContainer container;

        static void Main(string[] args)
        {
            container = new UnityContainer();
            container.RegisterType<ITestService, TestService>();

            ReadTime();

            Console.ReadLine();
        }

        private static async void ReadTime()
        {
            var serverTimeReader = container.Resolve<ServerTimeReader>();
            var serverTime = await serverTimeReader.GetTimeAsync();

            Console.WriteLine("Server time:" + serverTime);
        }
    }
}

It's a console app so the entry point is static Main method which creates a new instance of IoC container (Unity in this sample) and adds to the IoC container mapping of the server side service contract with the service client I wrote

Then client calls a ReadTime method which uses IoC container to resolve ServerTimeReader instance injecting to it during that resolution a service client instance. Then the code awaits the GetTimeAsync method which awaits the service client call which results with a asynchronous call to a server being made and awaited on client.

Once the server returns the result to client the client shows it in console – that’s it.

image

Conclusion

The simplicity of the code performing fully async call to a WCF service is so brilliant that I am not going to write unit test here for the GetTimeAsync method because it should be quite obvious how to do that. The code is almost the same as it would be if it was written for sync WCF calls and to learn just how to tacklethe TPL/async specific things check out this stack overflow page recommended by my friend Slobodan Pavkov

That’s it folks – hope this will be useful to someone!

25Nov/105

Naked MVVM – simplest way to do WCF code

How to get testable WCF code in simplest way?

What is the problem?

We all know that creating an instance of service proxy inside of the view model makes writing tests for the view model very hard because during the unit test run we don’t have usually the web service on the other side or even if we do it slows down web tests.

You know how they say

“Unit test is the test which runs without any problem with network cable unplugged”

Like the previous post about simplest possible way to do MVVM, the solution for this problem was covered in so many blog posts that even I am personally aware of a couple of cool and ‘frameworkish’ ways to solve it: use WCF behaviors, create your own ChannelFactory<T> with either sync call in separate thread or IAsyncResult based approach and (my personal favorite) hack the Visual Studio proxy generator. I’m sure there are at least 24 more solutions to do this Smeško

Still, there are two main problems with all the approaches I saw which belong to one of the next two groups:

  1. They deal purely with async based scenarios.
    If I have a service with a method GetForecast(DateTime date), I don’t want to maintain another interface just to get a way to make async call.
  2. They are rocket science type of solutions
    We are all geeks and like nice and shiny toys, but what about regular folks like me and a lot of the readers? Is there a really simple way to do this for “us others”?

Luckily, I think I found one which is definitely not the coolest one and 100% can be enhanced etc, but it is the one which proved to me in my day to day WPF/SL coding to be the easiest one “to grok and use”.

Conceptual solution

imageThe solution follows next design goals:

  • doesn’t require any typing
  • it is using Visual Studio proxy generated with “Add service..” menu action
  • it is using the well documented MethodAsync() invoker, MethodCompleted event subscriber pattern
  • it is using T4 to auto generate code which enhances the VS generated service proxy
  • every service proxy file follows naming convention of ending with word “Proxy”

A year ago, I have blogged in great detail about the unfortunate fact of ServiceClient generated in service proxy not implementing an IServiceClient interface. In case you want to understand what my solution do under the hood go read that blog post now and then continue reading this one. In case “you don’t care how it works as long it is working” here’s a very short summary for you:

ServiceClient generated by proxy generator is marked as partial class.That allows me to create another partial class with same name and namespace outside of proxy which only purpose is to hook the IServiceClient interface I generated manually based on the ServiceClient itself.

In the original blog post I do it manually which ended as a PITA due to the fact that every change of service contract one has to keep updated the interface. As a result of noticing that I waste a lot of time on that, I spent 20 minutes and created a simple T4 class which does that automatically for me.

You can download the source code of end solution here.

Before

Project structure is very trivial. It is vanilla Silverlight project which has a TimerService WCF service doing just this

using System;
using System.ServiceModel;
using System.ServiceModel.Activation;

namespace NakedMVVM.Web
{
    [ServiceContract]
    [AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]
    public class TimerService
    {
        [OperationContract]
        public string GetTime()
        {
            return "Yes it works on " + DateTime.Now;
        }
    }
}

Once we add a service proxy to NMVVM_WCF project (NOTE that proxy name ends with Proxy)

image

We can happily write now our demoware code “…

namespace NMVVM_WCF
{
    using System.ComponentModel;
    using System.Runtime.Serialization;

    using NMVVM_WCF.TimerServiceProxy;

    public class MainPageViewModel : INotifyPropertyChanged
    {
        public MainPageViewModel()
        {

            TimerServiceClient client = new TimerServiceClient();
            client.GetTimeCompleted += OnGetTimeCompleted;
            client.GetTimeAsync();
        }

        private void OnGetTimeCompleted(object sender, GetTimeCompletedEventArgs e)
        {
            Message = e.Result;
        }

        [DataMember]
        private string message;

        public string Message
        {
            get
            {
                return this.message;
            }
            set
            {
                if (this.message == value)
                {
                    return;
                }
                this.message = value;
                this.OnPropertyChanged("Message");
            }
        }

        public event PropertyChangedEventHandler PropertyChanged;

        public void OnPropertyChanged(string propertyName)
        {
            PropertyChangedEventHandler handler = this.PropertyChanged;
            if (handler != null)
            {
                handler(this, new PropertyChangedEventArgs(propertyName));
            }
        }
    }
}

Nothing wrong with this code per se, just it makes unit testing of the view model much harder task then it should be…

After

To fix this problem, let’s do next 2 steps:

  • download the T4 template file (no need to look in what it contains at all) from here .
  • add the file to the root folder of NMVVM_WCF project using VS IDE “Add existing item”

As a result of this activities t4 template was executed and a file with ClientEnhancer was auto-generated with next content

	namespace NMVVM_WCF.TimerServiceProxy
	{
		public partial interface ITimerServiceClient
		{
			#region Events
			event System.EventHandler GetTimeCompleted;
			event System.EventHandler OpenCompleted;
			event System.EventHandler CloseCompleted;
			#endregion Events

			#region Methods
			 void GetTimeAsync();
			 void GetTimeAsync(object userState);
			 void OpenAsync();
			 void OpenAsync(object userState);
			 void CloseAsync();
			 void CloseAsync(object userState);
			#endregion Methods
		}

		public partial class TimerServiceClient  : ITimerServiceClient
		{
		}
	}

As you can guess, that's complete code I was coding by hand and keep it updated manually with service contract changes. Having this in place it is quite easy to change ViewModel to accept the IServiceClient as a constructor parameter

        public MainPageViewModel(ITimerServiceClient client)
        {
            client.GetTimeCompleted += OnGetTimeCompleted;
            client.GetTimeAsync();
        }

        private void OnGetTimeCompleted(object sender, GetTimeCompletedEventArgs e)
        {
            Message = e.Result;
        }

The only thing left is to update the MainPage.xaml.cs file

namespace NMVVM_WCF
{
    using NMVVM_WCF.TimerServiceProxy;

    public partial class MainPage
    {
        public MainPage()
        {
            InitializeComponent();
            DataContext = new MainPageViewModel(new TimerServiceClient());
        }
    }
}

And that’s it – application works like it was and we have a highly testable view model using only service client interface which is easy to stub/mock.

Having a hard time figuring out path from “before” to “after”? Here’s a short video showing step by step things just described

You can download the source code of end solution here.

Aftermath

My own version of this T4 template, beside the T4 template code used in this blog post is also auto filling IoC container with mappings to all of service clients and its interfaces generated by template. That auto generation combined with auto MVVM wire up I described in first post allow me to have this “TDD enabling of WCF service proxies” fully automated.

I decided not to put that additional template code so it won’t bloat the post with IoC containers etc, but it is VERY easy to modify and customize the T4 template – even if you never did it spend 20 minutes looking at .tt file I shared for this post and I guarantee you – you’ll get it.

The only downside of this approach is that you have to manually drop the T4 template file to every project with service proxies which in my case is not the problem at all – I add it once and after that it keeps things in sync on its own.

I am really not sure why Microsoft is not doing this in the default proxy generation process – it is not breaking anything or damaging backward compatibility and it enables easy testing. I was experimenting modifying the Visual Studio proxy generator myself, but I decided to abandon it (even it was working at the end) due to required registry modifications etc. In my opinion, dropping one file in project without any other requirements to make it testable is more transparent then other approaches and everyone could do this.

What do you think about it? Is it simple enough?

Filed under: Uncategorized 5 Comments
7Nov/1023

Naked MVVM–simplest possible MVVM approach

How to do MVVM in simplest possible way?

Yes, I am aware that there are at least 50 “How to do MVVM” blog posts and well known frameworks: prism, MVVM Light, Caliburn etc. Still, my friend Slobodan Pavkov convinced me to write a post and explain the approach I am personally using in my code, because (as he believes) it is so simple that it can be useful to someone -  so here I am - writing it down.
Idea is so simple that I guess it is very possible someone already blogged about it and if so please let me know so I could link that blog post here. I presume you know what MVVM already is – if not go read some of the hundreds blog posts about that and once you get it come back. My sample is done in WPF (as that is my LOB platform of choice) but it works without any changes in Silverlight too.
As all MVVM framework I had to pick a name reflecting the spirit of my “framework” and I ended with “Naked MVVM” because it reflects design principles I respect:
  1. No base classes of any kind required for framework
  2. No interfaces of any kind required for framework
  3. No attributes of any kind required for framework
  4. View first – Blend friendly & simple composition
  5. IoC enabled
  6. Works out of box as much as possible

Basic ideas behind “Naked MVVM”

Scenario

Simple MVVM framework requires simple possible problem: show in MVVM way a text box showing current date. That’s it – let’s roll.

You can download the source code of end solution here.

No base classes, interfaces and attribute

Usual implementations of MMVM I’ve seen usually have ViewModel<TView> base class and/or some form of IView view abstraction etc.
Here’s how View looks like in my approach
namespace NakedMVVM
{
    public partial class MainWindowView
    {
        public MainWindowView()
        {
            InitializeComponent();
        }
    }
}
And here is the view model containing all of the necessary requirements from my Naked MVVM framework
namespace NakedMVVM
{
    public class MainWindowViewModel
    {
    }
}
As you can tell from the code above, there are ZERO requirements from view and view model.

Wiring up the view and the view model

s you already know, the whole MVVM pattern is based on the idea that view data binds to a view model which then talks to a model.
image
A lot of samples I’ve seen, define some form of view abstraction which should enable view model to communicate with view on framework level.
All of those samples ignore one simple but VERY IMPORTANT fact – there is such abstraction already baked in .NET – FrameworkElement. Every view (user control, window etc.) inherits from the FrameworkElement and can be casted to it. The reason why I picked it up is that the framework element has a DataContext member (to bad it is not defined in some interface so I could replace FrameworkElement with it). Setting a user control data context to some value results with all of the controls in that window/user control being bounded to the same value.
To codify that thought...
namespace NakedMVVM
{
    using System.Windows;

    public class MainWindowViewModel
    {
        public MainWindowViewModel(FrameworkElement frameworkElement)
        {
            frameworkElement.DataContext = this;
        }
    }
}
The problem here is how an IoC container (one of the requirements above is to use IoC) can resolve this generic FrameworkElement constructor parameter? That question is exactly the reason why we have all of the IView and IView<T> in the MVVM blog posts. To me that well documented approach is an overkill because we create entities just to hold our infrastructure. Much better approach could be to resolve a framework element from a IoC container using a well known key. There are many way how to do that but let here illustrate it in the simplest to digest form using the ServiceLocator.
namespace NakedMVVM
{
    using System.Windows;

    using Framework;

    public class MainWindowViewModel
    {
        public MainWindowViewModel()
        {
            var frameworkElement = ServiceLocator.IoC.Resolve("MainView");
            frameworkElement.DataContext = this;
        }
    }
}
As you can see here, view model becomes a data context of a view without any artificial code artifacts created to enable that. If I wouldn’t have to respect my design principle #1 “No base classes of any kind required” I could extract this class to base view model class and have it applicable on all view models.
namespace NakedMVVM
{
    using System.Windows;
    using Framework;

    public class MainWindowViewModel : ViewModel
    {
    }

    public abstract class ViewModel
    {
        public ViewModel()
        {
            var frameworkElement = ServiceLocator.IoC.Resolve(this.GetType().Name.Replace("Model",""));
            frameworkElement.DataContext = this;
        }
    }
}
Too bad I am not allowed to do that so I am again deleting all of the changes in this ViewModel and restore it back to be an empty class with no base class and no wire-up code in it. To see what I do in my code you would have to be patient for a little bit more because I need to explain first may way of …

Filling the IoC container

In most MVVM samples, there is a bootstrapper class where developer enlist all of the IoC mappings. In this example it could be something like this
using System.Windows;

namespace NakedMVVM
{
    using Framework;

    public partial class App : Application
    {

        public App()
        {
            ServiceLocator.IoC.RegisterType<FrameworkElement,MainWindowView>("MainWindowView");
        }
    }
}
imageJust by looking at this single line of code, it becomes obvious that:
  • I have to do the same thing for every user control/window I have
  • I map always framework element to a user control/windows
  • The key I use to store it in IoC is the same as the name of user control/window
Every WPF/SL developer I know (including me) when doing MVVM follows the next naming convention:
  • every user control is suffixed with “View” and
  • every view model of a control is suffixed with “ViewModel”
In concrete case of the sample used in this blog post, user control is named MainWindowView and her view model class MainWindowViewModel
If we combine the 3 obvious facts given above with the naming convention we could easily come to the same idea as I did:
“Iterate all of the types in current assembly. Each one of them which name ends with “View” map as framework element using the full type name as a key. Each one of them which name ends with a “ViewModel” map as object with a full type name as a key.”
Translating that thought into a C# code class IoCBuilder in this sample was created containing this
namespace Framework
{
    using System;
    using System.Reflection;
    using System.Windows;
    using System.Windows.Controls;

    public static class IoCBuilder
    {
        public static void CollectViewAndViewModelMappings()
        {
            foreach (var type in Assembly.GetCallingAssembly().GetTypes())
            {
                var typeIsUserControl = type.BaseType == typeof(UserControl);
                if (typeIsUserControl)
                {
                    var typeIsView = type.Name.EndsWith("View", StringComparison.InvariantCultureIgnoreCase);
                    if (typeIsView)
                    {
                        ServiceLocator.IoC.RegisterType(typeof(FrameworkElement), type, type.FullName);
                    }
                }
                else
                {
                    var typeIsViewModel = type.Name.EndsWith("ViewModel", StringComparison.InvariantCultureIgnoreCase);
                    if (typeIsViewModel)
                    {
                        ServiceLocator.IoC.RegisterType(typeof(object), type, type.FullName);
                    }
                }
            }
        }
    }
}
Now when we have this code in place, we can replace the explicit mappings from our bootstrapper class to a framework call
namespace YAMVVM
{
    using System.Windows;
    using Framework;

    public partial class App : Application
    {
        public App()
        {
            IoCBuilder.CollectViewAndViewModelMappings();
        }
    }
}
Major upside of this approach (at least for me) is that respects design principle #6 and allows me to just add a view and a view model without thinking about IoC mappings etc.

My way of wiring up view and view model

Having in mind the content of IoC container and design principle #4 (Blendable framework) after a lot of experimenting I’ve realized that the behavior is the most suitable way of doing the wire up.
The behavior itself is quite trivial and it it reflecting the same approach as shown above in explicit wire up sample code.
namespace Framework.Behaviors
{
    using System.Windows;
    using System.Windows.Interactivity;
    using Framework;

    public class AutoWireUpViewModelBehavior : Behavior<UIElement>
    {
        protected override void OnAttached()
        {
            base.OnAttached();
            var view = (FrameworkElement)this.AssociatedObject;
            var viewModelName = string.Format("{0}Model", view.GetType().FullName);
            var viewModel = ServiceLocator.IoC.Resolve<object>(viewModelName);
            view.DataContext = viewModel;
        }
    }
}
Code is quite simple: pointer to a user control is being passed to a behavior. Following the naming convention explained above, I add the “Model”to the name of the view so I would get the specific view model key which I use to resolve view model from a container. Once resolved view model, I set to a DataContext of a user control being passed to a behavior. Same approach as the one in explicit sample, just encapsulated in the behavior.
Now when there is a framework level behavior, only thing a designer has to do to wire up a view and view model (I emphasize here again that both of them are following the #1-#3 principles and not having any base class, interface etc) is to fire up a blend and just drag&drop the AutoWireUp behavior to a control.
imageimage
Off course, for us developers executing next R# snippet and resolving namespaces is maybe more suitable solution
    <i:Interaction.Behaviors>
        <Framework:AutoWireUpViewModelBehavior />
    </i:Interaction.Behaviors>
Regardless of which way you would prefer, the end goal is achieved: view and view model are wired up on a unobtrusive way removing the need for infrastructure bloat used usually to enable that.

Putting it to work

If we run our sample, everything will work just fine (even with view and view model being completely empty) except we won’t see the current date on the screen so we can’t know for sure if it work or not, aren’t we?
Let modify the view to its final state
<Window x:Class="NakedMVVM.MainWindowView"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        xmlns:Framework="clr-namespace:Framework.Behaviors;assembly=Framework"
        xmlns:i="clr-namespace:System.Windows.Interactivity;assembly=System.Windows.Interactivity">
    <i:Interaction.Behaviors>
        <Framework:AutoWireUpViewModelBehavior />
    </i:Interaction.Behaviors>
    <Grid>
        <TextBlock Text="{Binding HeadingCaption}" />
    </Grid>
</Window>
and the view model
namespace NakedMVVM
{
    using System;
    using System.ComponentModel;

    public class MainWindowViewModel : INotifyPropertyChanged
    {
        public MainWindowViewModel()
        {
            HeadingCaption = "Yes it works on " + DateTime.UtcNow;
        }

        private string headingCaption;

        public string HeadingCaption
        {
            get { return this.headingCaption; }
            set
            {
                this.headingCaption = value;
                this.OnPropertyChanged("HeadingCaption");
            }
        }

        #region The usual INPC implementation
        public event PropertyChangedEventHandler PropertyChanged;

        public void OnPropertyChanged(string propertyName)
        {
            PropertyChangedEventHandler handler = this.PropertyChanged;
            if (handler != null)
            {
                handler(this, new PropertyChangedEventArgs(propertyName));
            }
        }

        #endregion    }
    }
}
Run the app
image
See, it works Smeško
You can download the source code of end solution here.
What do you think? Have you seen this approach in whole somewhere? Does it makes sense to you or it look to you just-another-fluffy-pattern-thing?
Looking forward to hear your thoughts on my approach!
Filed under: Uncategorized 23 Comments
26Jun/100

Windows LiveID – Microsoft red headed stepchild?

I personally believe Microsoft is missing (if not already missed) the opportunity to monetize serious potential of Windows LiveID.

For years already, there are more then half a billion user accounts (which surpasses current number of Facebook accounts) which Microsoft could’ve use to create serious advertisement revenue the same way Facebook is doing now. The value proposition for users is the fact that they don’t have to remember “yet another user name and password” which is a definite win – at least for me. For identity holder (Microsoft/Facebook), getting information on activities user makes across the web is clearly a win from marketing and advertisement perspective. It is such an obvious case of win-win scenario, that I don’t want to spend any more words on selling it to you, dear reader.

Microsoft (as with many other cool things – Ajax etc) pioneered the Sing sign-on concept more then a decade ago but didn’t do much with it allowing to OpenID, OAuth, Facebook Connect etc to emerge as industry standards.

The reason behind LiveID failure to reach world domination in identity space is related to the poor developer story which prevented wider adoption of the LiveID as “the one online identity”./ Having in mind we are speaking about the Microsoft  as developer oriented company I find that to be quite hilarious in one hand and a proof of lack of Microsoft strategic vision in this area. In other words, I believe no one cared(s) in Microsoft so much about getting the benefits from Windows LiveID as some startup might try to (who said Facebook Connect?).

Why Microsoft failed to dominate with Windows LiveID

Here are couple of reasons why I think thinks are like they are right now…

Year 2003, Microsoft attempts rolling out LiveID (at that time called Passport) to couple of big companies (including eBay and Monster) which dies in 2004. Whatever the reasons were, loosing two of such a big adopters in 2004 is (IMHO) VERY stupid because if it did happen I bet we would be all using LiveID across the web right now “with not much of an alternative”.

Year 2006, MS had a STS running on http://sts.labs.live.com. I can not imagine a reason why would something like that die but there’s no such thing today.
Having an STS (web service auth token issuer) is all I would personally care about in order to adopt LiveID in my apps.

On Mix 2008, they announced Windows LiveID SDK CTP which was up until yesterday the only way of integrating Windows LiveID with client apps and sites. They have also announced on the same mix that LiveID would become OpenID provider, but that didn’t long last too.

Beside this efforts, Microsoft was trying also to pitch LiveID in parallel using its own strongest weapon: Windows.

Microsoft's Windows XP has an option to link a Windows user account with a Windows Live ID (appearing with its former names), logging users into Windows Live ID whenever they log into Windows. To me that sounds very nice (I’ve already auth myself logging on my PC and established a trust relationship which for most of the web sites out there should be sufficient). The only problems with this is that is almost unknown feature. I did a smoke test asking 10 people I know which use Windows Live Messenger on day to day basis if they use it – none of them even knew about it. I don’t even have clear understanding how this thing gets installed other then guessing it gets bundled in Live essentials installer .

Then, there is CardSpace which is industry correct and secure way of handling our online identity information. All great, except for the fact that it is quite a mystery “how to use it” Smile. In 2007, there was a beta of  CardSpace LiveID integration but after that nothing happens.CardSpace being a part of most of Windows apps is such a untapped potential that it is hart for me to believe that no one is trying to utilize it more seriously.

Couple of things I hope Microsoft will do with LiveID in the future

Microsoft still has some chance to emerge as one of the leaders in identity space but to do that they might consider doing some of the next things:

  • promote “LiveID” to become a 1st grade citizen in Windows.

    Ask for LiveID to be entered during the windows installation process (most of us have it anyhow). Windows Live service would then (during the install process itself) issue Card Space managed card for a user. Right from the moment system would be installed, that card should be used on every LiveID site.
    Even better put that card on my Live SkyDrive so it could roam with me while I work on different computers. If not possible to be built in Windows (ether Win7 SP1 or Win8), can we at least consider building it in Internet Explorer 9?

    I know this could be probably breaking some monopoly law, but lets face it – MS didn’t become what it is playing fair but playing bold.
    Apple integrating MobileMe and Chrome integrating google bookmarks and Flash are doing exactly that.

  • Use LiveID on ALL of the Microsoft sites. No excuses. Period.
    Just check out last post on windowsteamblog.com which (ironic isn’t it) introduces newest LiveID “Messenger Connect” API.
    To post a comment you need to Sign In
    image
    but that is not using the LiveID  Smile
    image

    If you don’t trust in it, why should we?

  • Spread it across the web similar to Facebook ‘Like’ button (‘Post with Messenger’) 
    Here’s a sample of how Bing can be used to collect ‘Likes’ by adding a ‘Post With Messenger button’ which would send it to people on messenger contact list andor Facebook, MySpace etc… Even this would end with forwarding it to Facebook as ‘Like’ there is still value in collecting those data associated with LiveID…

Do the same with as much as possible social networking sites.
Aggregate the data and share it with us developers so we can personalize better our content (not only ads)..

  • Stay away from hustling users as much as you can
    Force me to log in only once in 24 hour or more.  I ‘m sure this goes against best security practices etc. but for most web sites it really doesn’t matter. Otherwise you shift from "login screen” to “nag screen“
  • Support other browsers the same you do with IE.
    What’s the story with the FireFox and Windows Live? One of my friends, decided to use DropBox instead of LiveMesh (even offered 250% more storage space) just because he hates LiveID. Reason: he uses Firefox and it looks like that “Remember me”check box on Firefox has slight dementia so the login screen is quite annoying Smile 
  • Support other security protocols
    LiveID as OpenID provider, OAuth etc… The more adapters the merrier.

Last but not the least - respect us developers

I got personally interested in this topic because I choose WPF for my LOB application I am playing lately and I decided to use LiveID for authentication (everyone I know has one – regardless how they use it).

My preferred approach to building this app is S+S (which I am not sure if is still official MS way to go) where a desktop client application gets powered by services from the web/cloud getting with this approach best of both worlds: best user experience on windows machines + data in the cloud.

I was so naïve when I decided to try tout LiveID to expect to find some LiveID STS web service to which I would pass user name + password + ApplicationID and get back in response membership token. Naïve because I didn’t even consider the possibility that such thing doesn’t exist which ended as a true case.I really don’t understand why there is no such offering by Microsoft as we speak.
 
The second in favor solution is “acceptable” experience Microsoft has in its own Live Essential suite tools.Here’s a sample of how to do it.

image

As you can see it is a simple client app window which I am not sure what it does on “Sign in” but whatever it does (POST or web service) I am ok with using it too.

What I don’t want:

  • login control being a web browser control showing the special windows live login html page
  • generic control where I can not change the text (my app + folks not speaking English)

Reasons why I don’t accept those two things are I guess exactly the same as the one Microsoft came up with  when deciding not to use it in their own products.

If Microsoft expects me to use LiveID in my WPF apps they have to provide me a way to get the same user experience they have in dealing with the same problem.

Yesterday Microsoft released new Messenger Connect SDK which contains a sample WPF application and WPF template which is encouraging. In order to run the sample, one need to register application with windows live which right now is done through connect where you fill the request form and someone sometime would consider it.

Based on a quick glance over the sample there are no obvious ”skinning” capabilities – no control just a direct call to some function. The only thing I could do while waiting (hopefully) to get an LiveID was to run the sample as it is out of the b ox and this is the result I got “HTML in a box” – not very encouraging.

image

I’ll wait for the application key before I make a final call but so far it doesn’t look like Microsoft cares about WPF + LiveID integration experience..

Keeping fingers crossed but not holding my breath …

del.icio.us Tags: ,
Filed under: Uncategorized No Comments
15Jun/102

What is wrong with Cosmopolitan theme

I am HUGHE fan of Metro design paradigm, so I was more then excited to check out Silverlight business application theme pack  containing the Metro theme template (“Cosmopolitan”) which was released officially couple of days ago.

I am not designer but still wanted to share with community my initial impression and that is: WTF.

Here is picture illustrating why..

UIWaste

Considering the fact that we are speaking here about the web site, the fact that there’s 300 pixel of wasted vertical space (~220 in OOB scenarios) is insane. Think about how usable this site would be used in typical netbook/laptop/slate (any smaller height wide screen).

What they should do is simply copy paste Zune minimalist approach which preserves the UI waste and maximize the central part of the screen showing content.

I am aware that this is template which can be customized etc, but we all know that in a lot of cases it won’t be customized at all and we might end with a bunch of web sites using “Metro theme” (especially once WP7 would be released) which would contribute to Silverlight reputation in a bad way,

In other words, while I really appreciate templates provided to us, I think Microsoft creative ninjas (or someone from the community)  should do a couple more iterations on Cosmopolitan template and make it more usable by default and then we would customize it with 2nd level menu etc.

Filed under: Uncategorized 2 Comments
2Jun/1017

5 reasons why Silverlight sucks in LOB (compared to WPF)

Recently, Brian Noyes and  Rob Relyea have touched the “WPF VS Silverlight” subject and considering the fact I was also recently thinking about it I wanted to share my thoughts on that topic too.

As I said in previous post, I’ve started at home blogging about the accountingLOB applications in Serbia and one of the questions I got challenged by one of my readers (who knows how BIG Silverlight fan I am)  is

“Would you be using Silverlight for your own accountingLOB application?”

Initially answer looked very clear to me: with all the improvements Silverlight 4 brought to LOB game, desktop like programming model and web deployment looks like a perfect fit for public facing application (outside of intranets)

But, after doing some more thinking on this subject, to my surprise I came up with the opposite conclusion:
WPF is better choice for serious LOB applications.

And here are 5 most important reasons why I think like this:

Silverlight 4 is not cross platform environment any more

The biggest advantage SL had over the WPF (in my mind at least) is ability to be deployed to non-windows machines (MacOS and Linux powered machines).
Having Silverlight 4 with a whole slew of COM+ dependable features virtually prevents creating a Silverlight 4 siteapplication which would run on Mac and Linux. At least, that is the state as of today I am aware – somebody please correct me if I am wrong in this.

The way I see this change is that Silverlight 4 is shifting toward being unique “cross-screen” (desktop, mobile and TV) platform which is perfectly fine with me just it doesn’t have any particular value in context of LOB applications).

UPDATE: I did found a couple of folks with Mac which were kind enough to tell me that on Silverlight.net site there is Silverlight 4 plug-in for Mac which (as long as COM+ features are not used) works fine.

Silverlight adoption rate is not good enough

According to later RIA Stats adoption rate of Silverlight is around 60%. I’ll put aside the fact that I am not seeing that number around me in Czech Republic and accept it as correct one with slightly different interpretation: 40% of PCs are not having Silverlight installed.

The funniest thing is that WPF has 99% adoption rate because every PC with Windows newer then Windows XP SP2 (including Vista and Windows 7) has  WPF installed on it. I am not sure how many Windows 2000 and Windows 98 machines are out there but whatever the number that is personally I don’t think anyone should care targeting that segment as very unlikely to invest any money in purchasing your LOB product.

Even if a PC is not having the .NET framework at all, the download size to get it on PC is just 28 MB which is bigger then 9 Mb size of MacOs Silverlight 3 plug in but who cares (with any non dial up connection it is matter of seconds). In my personal opinion, this is one of the most important WPF features in .NET 4 :)

Silverlight tooling is good enough. WPF tooling is better

Starting with VS 2010 and Blend 4 we can work in SL4 and Silverlight is getting much more attention (just look at the paces of silverlight and wpf toolkits and everything gets to be clear there) but using WPF allows me to use all of the memory profilers, dbg viewers, any framework I want etc. If you are in doubt what exactly I think with this here’s an example: Silverlight does support printing but in case of serious LOB applications you need all the muscle WPF offers. Think something like Crystal Reports for example.

Silverlight programming model is more constrained then the WPF one

Doing Silverlight applications, one is forced to adopt the “make async web service call and get a chunk of data and do something with it” which in my personal experience limits the productivity of LOB developer compared to the speed he has developing with WPF . There’s no direct access to DB (which is actually great) but that ignores the fact that some LOB applications might need just that. For example, application can be written to target local SQL CompactExpress which then is set up to replicatemerge deltas with the central enterprise server. Anything like that (and we know how this things can get crazy in enterprises) is not possible in Silverlight.

Another thing related to this is aspect of offline access. I am aware that Silverlight 4 does have isolated storage and yes it has a bunch of open source DBs sitting on top of it, but it is just a single user storage. In reality, quite often in serious LOB applications we are seeing office andor P2P network topologies where it is essential that you have a “proxy per office” or ability to sync directly the data of “user X”. I know that Sync Framework is coming for Silverlight in 2010 but it is not there now and I am not sure if it would support topologies other then client <->(Azure) server.

Silverlight is still technically inferior to WPF in some areas.

Read Brian's post to see what this point is about.

Conclusion

Now you heard 5 of my most important reasons why I choose to stick with WPF on this. Am I missing the point? Making a false statement? Do you have more reasons in favor of WPF or Silverlight?

Looking forward to hear the comments :)

Technorati Oznake: ,
Filed under: Uncategorized 17 Comments
12May/100

I am starting two blogs about accounting and eCom in Serbia

Shameless SEO plug-in for my new blogs :)

(This probably means that you don’t want to read rest of this blog post)

Recently I had more free time then I have it usually, so I’ve decided to spend some of my time blogging about a theme I was always passionate about: accounting applications and internet business in Serbia. I would be doing it on Serbian language because I doubt that anyone outside of Balkan would be interested in those topics.

I also started researching much more WPF programming which (together with Silverlight I’ve been practicing for some time) is a topic I think most of people are not very much interested in today’s web world so that’s where the blog silence on this blog comes from but I have collected over time descent backlog of post ideas (mainly around CAGPrism and the way I adapt it to my needs) which I plan to spit out in upcoming days on this blog.

Just in 0.01% case you would be interested in checking out my Serbian blogs (they do provide Google translate translations) here are the links:

Filed under: Uncategorized No Comments
17Feb/105

Using the entity framework POCO template with VS2010 RC (easier way)

A while ago Julie blog posted tutorial on how to use VS 2010 beta POCO T4 templates in VS2010 RC. While I found that post very helpful I had hard time following it and after a bit of playing I think I found easier way how to get POCO template working:

Here are n simple steps:

  1. Go to Announcing the Entity Framework POCO Template update for Visual Studio 2010 Beta 2 and download the attached zip file (or click here)
  2. Unpack it anywhere
  3. Run the C# andor VB installer
  4. Open Visual studio 2010 RC
  5. Add a POCO template (New ItemCodeADO.NET POCO Entity Generator

Open the Model TT file being generated by T4 (No need to do anything in *.Context.tt file)

Update L15 of the generated file to be

	EntityFrameworkTemplateFileManager fileManager = EntityFrameworkTemplateFileManager.Create(this);

Original content:TemplateFileManager fileManager = TemplateFileManager.Create(this);

Update L678 of the generated file to be

	fileManager.Process();

It is originally fileManager.WriteFiles();

And voila – your T4 template is operational without the need to copy anything, no need for VS2010 b2 image files.

Please let me know (here on blog or on twitter @malovicn) if you would have any problems with this steps

Technorati Ознаке: ,
Filed under: Uncategorized 5 Comments
13Feb/104

Knetlik conference was a lot of fun

Knetlik .NET conference is over – we had today several interesting presentations about different .NET aspects (ranging from Silverlight for Facebook to AOP PostSharp programming.

I was presenting “Quick introduction to DDD” and while I was trying to speak as fast as I could and to stay away from details and implementation I went well above 10 minutes. Not sure why not being able to present 37 slides in 10 minutes surprised me so much :) Other then breaking the time slot, I am satisfied with the presentation – remembered most of the things I wanted to highlight and I guess slides were fun enough (I was using Roman empire as a base for analogies) to be remembered so I hope when some of attendees would start reading the DDD books they would have much easier job in understanding the basic concepts.

I was stupid enough to start Camtasia on my lap top, so I’ve uploaded here my deck just in case someone would need them once Andrew would publish the recording.

Prague Silverlight User Group (SLUG)

On the side note, but equally important I met several folks and local DPE, which shared my enthusiasm regarding the Prague SLUG (SiLverlight User Group) so that is definitely something which would happen in 2010.

So, if you are interested in SilverlightWPF development and leaving in Prague, please join the group I have created here: http://pragueslug.groups.live.com/ so you would be informed when the SLUG meetings would start and we might use it for group discussions too. See you there :)

Filed under: Uncategorized 4 Comments
20Jan/101

Do you want to learn DDD in 10 minutes? :)

· I’ve been doing a lot of presentations in last couple of years and people attending them know how hard was to fit most of them to 2 - 3 hour time slot (big subjects – trying to get into details)

So, when Andrew asked me if I would like to be one of presenters and pitch some subject in 10 (ten) minutes max I accepted immediately because sounds so challenging (read: fun).

So, my subject I would be presenting is “Quick introduction to Domain Driven Design” which in case you are newbie won’t definitely “teach you DDD” but (I hope) would be of some help getting a grip on some key concepts which understanding I find VERY helpful while reading “the blue book”.

I’ll also give my best also to present it in a way which won’t bore you to dead so it should be fun experience even you are “not newbie”.

In case you want to find out more details about the conference and register for 2 hours of pure information injection, click here.

Filed under: Uncategorized 1 Comment