.NET, Featured, Silverlight, Headline, WCF RIA Services »

[21 Nov 2011 | 0 Comments]

design-museum-extra-normal-clock-2009Sooner or later, you’ll run into this, if you haven’t already: the dreaded timeout error (or NotFound error), especially with long running operations or queries. The problem? Not all timeouts are the same (to quote a famous writer: all timeouts are created equal, but some timeouts are more equal than others). An error like that can come from your binding (which has a SendTimeout property), but it can also come from your data layer: there are timeouts that can be set on your SQL commands, and on your SQL connections.

 

Let’s look into the binding timeout first. We’re using WCF RIA Services, so you’ll need to gain access to the binding on your endpoint. This can easily be achieved through the OnCreated method of your DomainContext, as such:

 

public  partial class MyDomainContext
{
    partial void OnCreated()
    {
        PropertyInfo channelFactoryProperty = this.DomainClient.GetType()
                                                  .GetProperty("ChannelFactory");
        if (channelFactoryProperty == null)
        {
            throw new InvalidOperationException(
              "There is no 'ChannelFactory' property on the DomainClient.");
        }

        ChannelFactory factory = (ChannelFactory)channelFactoryProperty
                                 .GetValue(this.DomainClient, null);

        factory.Endpoint.Binding.SendTimeout = new TimeSpan(0, 10, 0); 
    }
}

 

With this code in place (you put this where the generated DomainContext code resides – make sure you use the correct namespace, this must reside in the same namespace as your DomainContext), the SendTimeout on your binding is now set to 10 minutes: this makes sure the request can now last 10 minutes. You might notice there are other timeouts you can set here as well: CloseTimeout, OpenTimeout and ReceiveTimeout, but: SendTimeout is the one that defines the interval for the operation to complete before a timeout error is thrown.

 

Next on the list: the command timeout. If you’re accessing a database in your domain operation, this can timeout as well: the command timeout is what defines the maximum amount of time that’s given to the command to execute the provided SQL code (default: 60 seconds). For long running queries on your database, you will need to change this. We’re using WCF RIA Services, and let’s assume we’re also using the Entity Framework: on your DomainService, there’s an overrideable method, CreateObjectContext. This is where you can define the command timeout, as such:

 

protected override MyEntities CreateObjectContext()
{
    var objectContext = base.CreateObjectContext();
    objectContext.CommandTimeout = 1200;
    return objectContext;
}

 

And on the the last one: connection timeout. This is the time you allow to open a connection to your database. Typically, this should be small: if it takes more than, say, a minute to open your connection, you know something is seriously wrong. But if you want to change this (the default is 15 seconds), you can do it via the connection string:

 

Data Source=(local);Initial Catalog=AdventureWorks;
Integrated Security=SSPI;Connection Timeout=30

 

If you keep these 3 timeout values in mind, timeouts for (long running) operations should be a thing of the past.

 

Oh, one more thing: if you’re working with authentication, and your require authenticated access to your services, the authentication ticket could time out as well (you can define this value yourself), resulting in an Access Denied error. To avoid this, using sliding expiration (true by default) will already help a lot (and is a good practice for most applications). Next to that, make sure you correctly catch & handle errors of this type, by asking the user to log in again when his authentication ticket has expired. This is how this could look in your web.config file:

 

<authentication mode="Forms">
  <forms slidingExpiration="true" timeout="180"/>
</authentication>



Happy coding! :-)

General, Silverlight »

[8 Nov 2011 | 0 Comments]

As some of you might know, this blog isn’t the only place where I publish content: I regularly write articles that get published on other sites (and which I obviously can’t just duplicate on this blog, although I try to think about posting the links in an update), and some content is published as books or e-books as well.

 

As it was becoming increasingly difficult to keep an overview of what got posted where, I decided to add 2 pages to this blog: one outlining the content that’s published as a book or e-book, another one with a listing of articles, podcasts, … on other sites

 

I added these as an easy reference for myself (from time to time, I need to get organized ;-)), but as they might prove useful for you as well: a quick blog post. 

 

Enjoy! :-)

Silverlight, WCF RIA Services, Featured »

[4 Nov 2011 | 0 Comments]

When you’re working with WCF RIA Services, there are various ways to handle your validation: you can use the built-in data annotations, you can write custom validators on property level, on entity level, you can do cross-field validation, … and sometimes, you’ll need information in your validators that isn’t related to your Entity.  For example: your validation rule could be different depending on the role of the logged in user, depending on the location he’s at, …

 

For scenarios like this, you can use the ValidationContext: you can pass in a Dictionary<object, object> containing any state information you might need to ensure your validation rule works as expected.  For more information on this, you can find a great explanation at Jeff Handley’s blog.

 

That said, when you’re working with this, you might notice something strange when you put breakpoints in your validator: even though you’re passing in the correct state information through the ValidationContext, sometimes the Items collection might seem empty (just have a look around the internet, and you’ll notice quite a few people ran into this problem).  When someone mentions this problem, they’re typically using controls like a DataForm or DataGrid.  So, why is this?

 

Well: validation can be triggered at different moments, and by different controls.  Take a DataGrid for example: it triggers its own validation (for example: when you start editing a property). But the DataGrid control doesn’t have any knowledge of WCF RIA Services (Jeff also mentions this in his posts: you can never assume your validator will have access to the Items collection!). So: when validation is triggered by the DataGrid, it will execute the validators without the custom ValidationContext – therefore, the Items collection is empty (the same applies to services you provide) in those cases.

 

Luckily, validation is also triggered in the property setters (amongst other places), which does provide the correct ValidationContext, ensuring our validator works as expected.

.NET, Silverlight, Headline, WCF RIA Services »

[18 Oct 2011 | 0 Comments]

imageA quick heads-up: my 2-part article series on authorized navigation in Silverlight has been published at SilverlightShow

 

The first article tackles authorized navigation: allowing or refusing access to a certain page/View in your Silverlight application depending on the role of the user.

The second article concerns authorizing access to certain UI elements IN a View (instead of the complete View), depending on the role of the logged in user, and deciding what to do when the user hasn’t got the correct role (eg: do you want to disable the element, or do you want to hide it completely?).


The complete source code is included in both articles.

 

Update: a third part has been released, focussing on securing your service calls.


Happy coding! :-)

Silverlight »

[27 Sep 2011 | 0 Comments]

My publisher, Packt Publishing, is running a campaign at the moment in which you get 20% of each Silverlight book, 30% even if you order the e-Book version! 

 

So, if you were looking to learn some Silverlight, or enhance your skills, this might be the perfect time.  The campaign runs ‘till the end of September, and you can find all the details here.

 

(and of course, my Silverlight book is included in the deal as well ;-))

.NET, Featured, General, Silverlight, Headline »

[16 Sep 2011 | 5 Comments]

Windows 8 is here!

 

Well, it's been announced :-)  The last few days, a lot of new information has been released about Windows 8, specifically aimed at the new Metro-style apps.  Windows 8 will essentially feature 2 modes: the regular desktop, and the touch-optimized Metro style.  I'm not going to go into much detail about this: I'm guessing people who end up reading this post already know a thing or two about Windows 8.  But: I've been getting a lot of questions on this topic, so I decided to try and answer a few, and share my 2 cents.

 

start_screen

 

Some things we've been hearing: Windows 8 changes everything.  HTML5 + javascript is the way to go.  XAML is a first class citizen.   OH MY GOD IE10 Metro doesn't support plug-ins: Silverlight is dead.  Silverlight is alive and well.  Et cetera, you know the drill.

 

Time to take a step back.  Does this really change everything?  Is the change that big?  Well: I don't think so. 

 

What is Metro?  What about the regular desktop?

If you look at Windows 8, it actually falls apart in 2 vastly different experiences.  We've got the regular desktop, which is much like Windows 7.  Everything we know about Windows 7 still applies to Windows 8: all the applications we've built, including WPF, Silverlight, in-browser apps built with ASP .NET MVC, ... Winforms, even, still run on Windows 8. Aka: the .NET we know and love.  This is the way applications will be built for a long, long time: just as we do it now.

 

And then there's the big new thing: Metro-style apps.  This is what all the fuzz is about.

 

One way to look at this, and this is the way I like to look at it, is: in fact, Metro style Windows = iOS or Android, the Microsoft way.  It's made for tablets/slates, it's made to be touch-optimized.  It's aimed, mainly, at consumers, or at apps that don't require a lot of input.  And every app you build for it will be built using the new development paradigm: WinRT, in combination with HTML/js or XAML/C# (I know, VB .NET etc is also possible - but let's just assume the majority uses C#), and they will be distributed through the Windows App store. 

 

win8-platform-and-tools

 

WinRT (regardless of how you talk to it - through JavaScript or C#) allows us to talk to device-specific functionality through C# or js (although it does still run in its own sandbox).  That's "The Cool Thing".  But in essence, writing Metro-style apps is a lot like writing apps for Android or iOS: you've got the power to use most of the capabilities of the device, the distribution mechanism is more or less the same, and the apps are OS-specific. 

 

But at the same time: Metro style apps do not run on anything but Windows 8 - Metro style (nope, not even the regular desktop).  Metro apps do not run in a browser, do not run on other devices, do not run ...  well, you catch my drift.  Even though you code these apps using syntax that is much like the XAML/JavaScript you're used to, they are not redistributable through other channels.

 

So what have we got here?  A new type of apps, with lots of capabilities, built in a new way that's a lot like what we're used to, but not quite the same.

 

What about IE10?

A nice example of this is IE10: there will be 2 versions of this: a regular IE10 for the desktop, and a Metro Style IE10.  This is actually just a Metro Style app: that version will not run on anything else but the Metro Style desktop.  By the way, this also means that other browsers like Chrome, Firefox, ... do not run in Metro Style mode - unless Google & Mozilla create Metro-versions of their browsers, and Microsoft allows it.  Just like none of your existing apps run in Metro Style mode (you might start to see why I like to think of this as "MS's iOS" :-)).

 

Now, of course: web applications do work, as you're just browsing to them using IE10, Metro Style.  But don't be mistaken: these are the web apps we're used to, and they are confined to the browser sandbox, just as we're used to.  They do not have access to any of the WinRT-stuff.  It's, well, just a browser.

And what's more: it's a browser that does not support plugins.  None.

 

Well, that sucks.  Shouldn't these plugins be supported?

No plugins.  That means: no Flash.  No Silverlight.  But also: no Adobe Reader, and none of the other plugins a lot of LOB applications rely on. 

 

There's been a lot of concern about this: does this mean Silverlight is dead?  Or Flash?  Isn't this a very bad decision? 

 

No: it's a good decision.

 

It's like wanting to have support for Flash or Silverlight, in-browser, on your smarthphone or iPad.  It can be done, technically (there's a Flash for Android), but it will offer sub-par user experience, almost by definition.  Steve Jobs was right on this one: if you create a Flash app (or Silverlight app for that matter) that runs in the browser, it's supposed to be manipulated with keyboard & mouse.  Using an app designed for those input types on a touch-based device is not - and I mean: never - a good user experience.  Let alone the different amount of screen estate, orientation, ...  any designer will tell you a specific form factor with a specific input type requires an application design catered to those specifics. 

 

From an end-user POV, not supporting plugins in Metro is a good thing.  And for those who are concerned about Flash or Silverlight: this is, and stays, fully supported in regular Windows 8.  Remember: Metro apps are touch-centric apps, for slates and tablets.

 

Touch centric?  Metro?  Isn't this supposed to work with mouse & keyboard as well?

Yes, it works.  But this is one of the things where I'm quite opposed to what Microsoft is trying to sell us with its Metro paradigm: the idea that Metro works just as good with mouse & keyboard. 

 

With Metro, we're looking at a UI and UX tailored to touch devices.  As any - and I mean any - UX specialist will tell you (and as I've stated above): a different input methodology requires a different UI approach to ensure good UX.  Even Microsoft themselves tell us that: just read their Metro design guidelines for WP7: it's based upon the notion that a touch-centric UI is vastly different from one in which you manipulate your apps with mouse and keyboard.  So, Metro with mouse and keyboard?  It's not because it can be done that it should be done.

 

My gut feeling?  The typical LOB/Enterprise applications that require mouse/keyboard input will not be Metro applications - they will look, feel, and be developed just as we do today, web-based or desktop-based, and will be run through the regular desktop in Windows 8.

 

Conclusion?

With Windows 8, we get a new type of application: the Metro style app: touch-centric, Win 8 only apps, using a new WinRT stack, which can be developed using XAML/C# or HTML/JavaScript (keeping in mind that those apps will not just run in a browser, or in Silverlight).  This Metro style version of Windows is, in my opinion, quite similar to what we've got with iOS/Android-based devices.  The thing Windows 8 has going for it is the ability to switch between Metro & regular mode, but we've got to keep in mind that these are 2 very, very different environments, from a user POV AND from a development POV.


But for the most part, and for the majority of applications that are built today by companies as the one I work for, there's not that much that changes: we typically buildLOB / Enterprise apps, not very suited for the touch-based, small application, consumer-like approach Metro is tailored to.

 

The best advice I can give anyone who’s building applications today: build a decent, standards-based service layer, and tailor the frontend to the devices it has to run on, be it a regular web app, a Silverlight OOB app, an iPad or iPhone app, or a new WinRT Metro Style app.  The “build once, run everywhere”-dream should be put to rest.  The best user experience is, and stays, a native experience.

.NET, Silverlight, WCF RIA Services, WCF, RIA »

[14 Jul 2011 | 0 Comments]

Just a quick heads-up: in case you haven’t noticed, Silverlight Show started publishing e-books a few weeks ago.  These provide a convenient way to read up on some of their most popular article series, including source code, while you’re offline.

 

I’m glad to announce that two of my article series are now available as e-books:

 

 

Happy coding! :-)