General, .NET, Silverlight »

[10 Feb 2010 | 2 Comments]

As some of you might know, a new RC has just been released for VS2010 – it’s supposed to be much more stable and faster than the second beta.  However, as of now, there’s no Silverlight 4 support, we’ll have to wait for a new release of the Silverlight assemblies.  Which means those of you – including me – who use Visual Studio 2010 for Silverlight 4 development are stuck with the beta for now.

 

And the beta isn’t exactly crash-prone, especially in combination with Silverlight.  However, there are a few things you can do to improve your experience.  One of them comes down to disabling the Highlight References feature, which I just read about on the design-time writer’s block

 

I would like to add another tip to that, which greatly reduced the number of crashes (not just on startup, but throughout development) for me: start up Visual Studio 2010 beta 2 without the splash screen, by using devenv.exe /nosplash.

 

Hope these few tips help some of you out!

General, Silverlight »

[4 Feb 2010 | 2 Comments]

Hi there!  After long consideration, I decided to move away from my old blogger blog, buy a domain, ASP .NET webhosting, and start using BlogEngine .NET for a new, updated blog.  Which is what you are looking at right now ;-)

 

Why BlogEngine .NET?  Well, mainly because I’ve heard good things about it, and, as I’m a .NET programmer, I can change it if something doesn’t exactly suit my needs.  Next to that, there’s very nice integration with Windows Live Writer, which is what I use to write my blog posts. 

 

I’d like to give a quick shoutout to Aaron Lech, whose post on exporting blogger blog posts to import them into BlogEngine was really, really helpful.

 

Anyway, I hope you like the new look (I might change it around a bit here and there – and I nice logo wouldn’t be a bad idea either ;-)) - feel free to stick around.

Silverlight »

[6 Dec 2009 | 1 Comments]

In the next few days (Monday, Tuesday, Wednesday, December 7th-10th), I’ll be giving a bunch of presentations on Silverlight 3/4 on various locations in Belgium (Antwerp, Brussels, Ghent, …).  I’ll talk about the new features in Silverlight, show how to use Blend and Visual Studio for Silverlight development, talk about WCF RIA Services, et cetera.

 

You can find the slide deck and demo code on my SkyDrive.

 

See you in the next few days? :-)

Silverlight, Featured »

[1 Dec 2009 | 0 Comments]

In Silverlight, if you’re talking to WCF services, you have the built-in option to add credentials to the message header and check those on the server side.  This way, you can easily make sure your service methods are only accessible to those people/identities you want to allow.  More detail on how to achieve that can be found on MSDN: how to use message credentials to secure a service for Silverlight applications.

 

There’s one little caveat though: to be able to use this, you MUST use transport security (SSL), which is defined by the HttpsTransport element in your config files: Silverlight will not allow you to send the username/password in the message header using these bindings unless you’re using SSL.  This is actually a good thing: having this as a requirement makes sure developers don’t “forget” to use SSL – forgetting that would result in serious security implications, as all the information would be sent over the wire in clear text (or binary encoded, but that’s still quite easy to hack).

 

Now, you’d typically want to set up SSL in some kind of test environment by using a self signed certificate (you’d buy one when going to an acceptance/production environment), and that’s where the problems might begin: Silverlight doesn’t exactly play nice with self signed certificates.  Looking around for that on the net will result in numerous posts, where some people say it’s impossible, some get it to work, but apparently, there’s no clear way to get this to work all the time, everywhere.

 

Well, I recently found myself requiring secure services over SSL in a Silverlight project, and I needed to use a self signed certificate for this (to learn how to create one, have a look at this post by Scott Guthrie).  Sure enough, I set up everything right (using the new Silverlight 4 beta, and I even made sure I added the certificate to the trusted root), and … it didn’t work.  Dreadful “NotFound” errors everywhere.

 

So I started looking at my bindings in the config files, double checked the service implementation, regenerated the proxies, …  nothing worked.  But after a while, I noticed something: as I was using SSL on a local IIS install, Visual Studio put “localhost” as the root address – which is the default.  I changed this to my web servers’ name instead of localhost, and sure enough: it worked!

 

iis5

 

So, if you’re running into problems with Silverlight and self signed certificates, you might want to try this:

 

  1. Create a self-signed certificate
  2. Create a website using this certificate for SSL
  3. Make sure you’re not using VS’s internal development server (doesn’t work with SSL), use IIS, and point to your newly created website.
  4. In the project settings’ web tab, point the IIS address to the computer name, and not to localhost.

Hope this helps some of you out! :)

Silverlight, .NET, General, WPF »

[24 Nov 2009 | 0 Comments]

A few weeks ago, the new VS2010 beta was released, including a long-awaited upgrade of WPF, which enables features like the Visual State Manager for WPF.  Next to that, a beta of Silverlight 4 was released at PDC last week, which – amongst others – enables SL Out of Browser to run in a trusted environment, thus enabling it to access (parts of) the local file system and COM interop.

 

From that moment on, the internet has been buzzing with questions and concerns about when one should use WPF and when SL when building a rich app using the Microsoft stack.  On ZDNET, an article appeared which stated that everything would be rebranded to Silverlight – so the term “WPF” will be obsolete in the (near?) future.  We’ll just have different subsets of Silverlight.  How this is going to be implemented remains to be seen.  This is what the article has to say about that:

 

Some day — Microsoft won’t say exactly when — Silverlight and WPF are going to merge into one Web programming and app delivery model that, most likely, will be known as Silverlight, Brad Becker, Director of Product Management for Microsoft’s Rich Client Platforms, told me this week at TechEd. Now that the two share the same compiled assemblies, tools and the like, that idea isn’t really so far-fetched.

 

So, what do you do when you want to decide on using WPF or SL for an application?  That’s probably a question a lot of people are asking themselves at the moment – this question for sure sparked some heated but very interesting discussions at my company. :-)

 

Just stating “WPF for desktop clients, SL for web clients” doesn’t cut it anymore now that SL can run on the desktop, even on Mac, trusted.  It even provides you with a very, very easy upgrade model (simplified: update the XAP on the webserver, and all clients, even the OOB installed ones, will be updated automatically). 

 

Some business requirements automatically make the choice for you: need WS security standards?  Use WPF.  Need heavy 3D graphics?  Use WPF.  Need full local file system access?  Use WPF.  Do not try to get Silverlight to behave as a WPF client by using workarounds – if you need a workaround to get something done that’s included out of the box in WPF, it’s probably better to just use WPF.

 

Next to that, I – personally, not necessarily my company’s view – would use Silverlight, even for desktop applications.  Why?  Well, that’s more a matter of how I think applications will/should evolve than anything else. 

 

Let’s elaborate on that a bit.  It’s clear that the division between the online and offline worlds is fading.  People want to be able to access their applications and data anytime, from everywhere.  Silverlight is already a nice fit in this model: it runs in the browser and on the desktop when needed.  We can now develop an application that can easily be installed locally or accessed through the browser, without actually having to develop 2 separate applications.  And if you absolutely need two separate apps, one which has more features than the other, you could share most if not all your code.

 

Now, back to the “rebranding of WPF to SL”.  I’m hoping that Microsoft, won’t just rebrand this, but that they’ll go for a new, truly pluggable model.  At the project start, you should decide what requirements your application needs, and depending on those requirements, certain features will be enabled or disabled.  The Silverlight Core CLR could be the base feature set (so: no more differences in XAML markup/features between SL and WPF), and if you need more functionality, your project should just reference the necessary assemblies, which would then be included in the XAP (of course, assembly caching and XAP shrinking should be used here). 

 

This would allow for true plugability: does your application need to comply to the WS standards?  Reference the necessary assemblies, and it will.  Does your application need full access to the local file system?  Reference the necessary assemblies, and it will, but it will of course disable some features in the online version of your app. 

 

 

In a sense, what I’m aiming for is not plugability of certain features, and not just a few different sets of the .NET framework to choose from, but the ability to be able to plug in parts of the .NET framework when needed – much like you plug in third party controls.  One base framework (based on SL’s Core CLR), and a pluggable model for all the other namespaces.   Something to think about?

 

Silverlight »

[10 Nov 2009 | 1 Comments]

A while ago, we were busy developing custom controls for Silverlight (2 at the time).  One of those controls was a Wizard control, which in turn consisted of a list of another custom control, the WizardSlide.  Obviously, this list was implemented as a Dependency Property “WizardSlides” (collection of WizardSlide) on the Wizard control. 

 

However, after some testing, I noticed some pretty strange behaviour: everything worked quite fine when only one instance of the Wizard control was used in our application, but from the moment on we started using multiple instances, the WizardSlides-collection property seemed to behave itself as if it were defined on the class instead of on the instance of the class.  All of a sudden, we were able to access the combined WizardSlides of instances 1 & 2 through the WizardSlides property on either of the Wizard instances.  To make matters even more strange, this didn’t happen if the collection property contained a simple type (like string or int), but it did happen when it contained a UIElement (or derived) type (like the WizardSlide control). 

 

We tried lots of different approaches to solve this problem, searched the internet, posted questions on the Silverlight forum, but to no avail: no-one could explain why this happened nor offer a solution, and we finally opted for a less-than-ideal approach, constricting the number of WizardSlides to 8 instead of having a dynamic collection.

 

Last week, I was helping out one of our clients with their Silverlight application.  An application which uses custom controls.  One of which contained a collection that seemed to behave as a singleton instead of on an instance level…  I remembered the problems I faced with this before, already thinking we wouldn’t find a solution to keep this collection dynamic.  However, I started searching around again, and lo and behold, it wasn’t long before I found this page on MSDN, describing the exact problem we were facing AND offering a reason and solution.  I am, by the way, 100% sure this page wasn’t there last year ;-)

 

Apparently, what’s happening is this: when you create a dependency property, it gets its default value through the dependency property metadata you define.  If that property is a reference type, this default value isn’t a default value per instance, it is a default value that applies to all instances of the type.  This means that when using the collection defined by the collection property metadata (which is singular/static!) as the default value for new instances, your collection dependency property is actually referring to that singular collection, and is thus accessible through any instance of your control!

 

Interesting, no? :)  What’s even more interesting is that there is a very, very easy to solve this: to make sure your collection property isn’t shared between all instances of your control, reset the property value to a unique instance as part of the class constructor call.  In the Wizard control with a WizardSlides collection, this looks as such:

 

public Wizard() : base()
{
//... other constructor tasks

SetValue(WizardSlides, new ObservableCollection<WizardSlide>());
}

 


Hope this helps some of you out! :)

Presentations and sessions »

[9 Nov 2009 | 0 Comments]

In the next few weeks, I’ll be speaking at a few events.

 

  • Tuesday November 17th: RIA Evening Seminar @ KHM

I’ll be speaking about Rich (Internet) Applications, mainly focussing on Silverlight. In this 90 minute session. I’ll talk about the “why” and “what” of rich applications, and show off a few of the features that make Silverlight stand out.

Location: Katholieke Hogeschool Mechelen (website)

  • Wednesday November 25th: Microsoft User Experince @ Vitra

    For the second time, Microsoft is organizing this event together with Vitra & partners.  This event is aimed at developers & decision makers, and consists of in depth sessions on Sharepoint, Silverlight, WPF and Sketchflow in the afternoon (@ MS Corporate Village, Zaventem), and short introduction sessions in the evening (@ Vitra showroom, Diegem).  I’ll be presenting the Silverlight session: this is a 45 minute session, repeated throughout the afternoon.  In this session, I’ll talk about Silverlight 3 & its new features.

 

Don’t hesitate to say hello if you see me! :)