Comparison of Microsoft Silverlight 2 and Adobe Flex by an Adobe Evangelist

I've found a nice read on a comparison between Microsoft's Silverlight and Adobe Flex by an Adobe Evangelist who took a 3 day Silverlight 2 training.

The weblog post starts of with summarizing the good and bad things of Silverlight but it's also nice to read the comments where a big discussion starts between Microsoft employees, Adobe employees and other developers/designers that have to choose between these 2 technologies.

Things he likes about Silverlight:

  • “The first thing I really like is the concept of threading. Being able to spawn off complex tasks without choking the main thread is pretty cool. You could, for example, show a really smooth animation when you are loading a bunch of data in a separate thread.”
  • “A Silverlight application can directly communicate with the HTML document it is hosted on by simply setting a parameter.”
  • “Being able to code in either C# or VB.NET is also a great feature. Especially since these two languages are pretty familiar to people developing for the Windows platform. I’m not one of them, but I found that C# is similar to ActionScript. Next to those languages you also have XAML, which does more or less the same things as MXML.”

    after that he tells us the things he doesn't like about Silverlight:

  • Code in XAML and C# is really verbose.”
  • “Styling controls is an absolute nightmare! I honestly think that this is going to be Silverlight’s Achilles’ heel!”
  • “Another thing that I really couldn’t grasp is the lack of HTML tag support in text fields.”
  • “I know the Expression tools are still in beta, but it has to be said that all the tools (including Visual Studio, which is no longer in beta) felt extremely buggy and incomplete.”
  • “Over these three days, I got a strong feeling that Silverlight was created by people who don’t know anything about designers.”

    In my opinion Silverlight and Adobe Air/Flex can both be big and good in their own things and eventually they will start growing towards each other as .Net and Java are also doing. Adobe has its huge designers userbase while Microsoft has a very big developers userbase. I think Adobe will stay the best thing to use for really nice fancy looking webtools while Silverlight will focus itself on the real rich internet Applications instead of websites which will stay the big focus of Adobe.

    I do agree with him that styling can be pretty hard for designers which aren't used to set all those properties and maybe Silverlight is a bit TOO extensible for them. As an example he shows how to change the rotation of an object in Silverlight and Flex:

    Microsoft Silverlight Adobe Flex

    <RotateTransform Angle="45"/>

    <Button rotation="45"/>

    I can see a designer will like the simple rotation property but Microsoft gives us (developers) the option to do all kinds of transformation on the object which is more extensible then the way it's done in Flex.

    About the point where he is complaining about how buggy everything is, I think this changed in a good way from Silverlight 2 Beta 1 to Beta 2 and I'm sure that everything will be really stable at the final release. (of course Visual studio isn't in beta… but the Silverlight developer tools are so that's why Visual studio isn't always that stable while building Silverlight applications at the moment)

    I do think Microsoft will have a hard time to get designers to change to Silverlight from their loved environment which they already know but only time will tell.

    Geert van der Cruijsen

    Share on Facebook
    Kick It on
    Shout it
    Post on Twitter

    Last.Fm Radio Stream Player Gadget 0.5 Released!

    Update 08-06-2010: the gadget does not work anymore. changed their client server protocols and therefore the gadget is not working anymore. I’m not using anymore so i’m not planning on updating the gadget in the future



    Last week my mailbox was flooded by mails of people who were telling me my Windows Vista Sidebar gadget to play radio was broken.

    I tested it myself and concluded that this was indeed the case. changed their website last week and my guess is that they also changed their streaming service.

    After a full night of debugging I found out what was the problem and I fixed it in a new version which can be now downloaded from the download area.

    If you are interested in what was changed read on. The change was fairly simple, the protocol uses 2 handshakes to connect to the service. The first handshake is to connect to the scrobbling service. The second handshake is used to connect to the streaming service. Before last week requesting the mp3 stream was done by sending the sessionid of the first handshake. Now… it seems you have to send the sessionid you get with the second handshake. It took some time to figure this out but now everything seems to work fine again.

    Protocol example:

    Handshake 1 request:

    Handshake 1 response from

    session=bbe5e763d1e1deb988595cecf1c21e9d stream_url= subscriber=0 base_path=/radio info_message= fingerprint_upload_url= permit_bootstrap=0

    Handshake 2 request:

    Handshake 2 response from

    OK 7e5b82460d2a45e382b81c437ae6a87a

    Tune to the right radio channel:

    Response to channel change request from

    response=OK url=lastfm://artist/muse stationname= Muse’s Similar Artists discovery=true

    Request metadata of stream:

    I was happy to receive the mails of complaints because this is proof people are actually using my gadget :) Hopefully all problems are fixed now so happy listening!

    Geert van der Cruijsen

    Share on Facebook
    Kick It on
    Shout it
    Post on Twitter

    MOSS workflow wont start because ‘The requested workflow task content type was not found on the SPWeb’

    The last 2 days my MOSS environment was driving me crazy because an already existing workflow didn't want to start in a new document library in a new subsite. I made this workflow in Visual Studio 2005 and deployed it as a feature to my SharePoint Site. I connected the workflow to a content type and told it to run on new items of this type or whenever an item changes. This workflow worked fine for 2 months in this particular document library.

    After 2 months my client asked for a new subsite with a new document library where this workflow should also run. I installed this workflow here and expected everything would go as planned. When I tried to test the workflow I didn't see anything happen so I tried creating new items, changing them, even manually starting the workflow. Nothing happened. The metadata field which contains the workflow status was staying empty. When checking the log files I didn't see anything either.

    I tried to reinstall the workflow. Deleted and recreated the site nothing seemed to help. During all this the workflow still worked fine in the other subsite and document library. When I recreated the workflow and checked the logfile again I finally found an error. (it seems Sharepoint only logs this error the first time you start the workflow and after that it doesn't do anything)

    The error message in the logfile was the following:

    Workflow Infrastructure        72fv Unexpected AutoStart Workflow: System.ArgumentException: De aangevraagde werkstroomtaakinhoudstype is niet gevonden op SPWeb.     at Microsoft.SharePoint.SPList.PrepForWorkflowTemplate(SPWorkflowTemplate wt)     at Microsoft.SharePoint.Workflow.SPWorkflowManager.StartWorkflowElev(SPListItem item, SPFile file, SPWorkflowAssociation association, SPWorkflowEvent startEvent, Boolean bAutoStart, Boolean bCreateOnly)     at Microsoft.SharePoint.Workflow.SPWorkflowAutostartEventReceiver.AutoStartWorkflow(SPItemEventProperties properties, Boolean bCreate, Boolean bChange, AssocType atyp)

    this Dutch error (I really hate Dutch errors. you can't look them up on Google/MSDN:( )translated in English is 'The requested workflow task content type was not found on the SPWeb'. I found the exact translation because I was lucky and when I had the English error this gave me new hope to find a weblog with the answer (since weblogs seem the primary documentation for SharePoint 2007 ;) )

    I searched for the error and everything I could find was reinstalling the OffWFCommon feature. I tried this with the following commands but nothing changed. I also tried to uninstall and reinstall but this didn't help either

    stsadm -o installfeature -filename OffWFCommon\feature.xml
    stsadm -o activatefeature -filename OffWFCommon\feature.xml -url http://localhost/

    This weblog told me the exact thing that was going on. the TaskListContentType wasn't installed on my tasks documentlibrary when I checked it by enabling content types chaning in the advanced settings of the tasks list. The ID of this content type is 0x01080100C9C9515DE4E24001905074F980F93160 which is the same as the OffWFCommon feature so it definitely had something to do with it. When I checked the content types of my task doclib that was working I noticed it had 2 content types attached. 1 called "Task" and 1 called "Workflow task content type" my Tasks library that wasn't working had a content type called "Tasks". I couldn't find any way how to add these content types because these are system content types and thus hidden.


    Since I already wasted 1 and a half day on this problem my next try was to save the Tasks documentlibrary of the workflow that was working as a template. After that I deleted the workflow in the new document library and also deleted the Tasks list there. I added a new Tasks list by using the template I made and installed the workflow again for this documentlibrary. I tested it and guess what.. everything seemed to work fine. The solution isn't that pretty but I was glad it finally worked!

    Hopefully someone with the same problem reads this before they waste to much time on this really awful problem. Also if you know  a better solution please let me know because I would really like to know how to really solve this problem.

    Geert van der Cruijsen

    Share on Facebook
    Kick It on
    Shout it
    Post on Twitter