N.B. 8/18/2008: It looks like the moderators finally took the thread down; it was so full of hate posts and name-calling and ad-hominem attacks, its about time!

They just don't understand: Have you ever had your browser freeze up when requesting a page somewhere which request (or even a subrequest in the page, such as for advertising or an image) doesn't come back right away? Your browser turns white, your whole damned desktop is frozen, and you may need to get rid of IEXPLORE.EXE from within Task Manager just to free up your system (in rare cases you may actually have to shut down and reboot). This is what happens when a developer who doesn't know how to write asynchronous code issues a blocking, sync method call and then “something bad” happens. Remember - HTTP is NOT a reliable protocol!

Since Silverlight's UI runs on a single thread and most all network code takes time to return (if it actually ever does return) it would be unacceptable if the Silverlight plug-in would just block waiting on an HTTP or Socket call -- thus blocking the UI of the host (your web browser). So, the Silverlight Team decided to only use the asynchronous model for all network related calls – whether WCF or WebService proxy calls, WebRequest, or WebClient. They simply implemented the same NPAPI plug-in architecture that all plug-ins must use. It’s sad, because a couple of “holier than thou” posters on that forum thread were quoting my statement from the paragraph above and telling me that I was stupid! Not stupid at all – the whole purpose of the plug-in architecture only permitting async requests is so that plug-ins would not be able to lock up the browser!

The bottom line is this: if Microsoft were to allow every petition-signing Tom, Dick and Harry blowhard / hotshot developer to make synchronous calls because they are too lazy and crybaby to learn how to do it better, there would DEFINITELY be a lot of very unhappy people with frozen browsers out there in SilverLand -- and guess who would get blamed? Microsoft!

I see that many are trying tricks like using ManualResetEvents and other threading primitives to try and “simulate” synchronous behavior. My advice? Don’t even bother to try – it’s so much easier and more professional to just learn how to write -- and THINK -- async. Your typical .NET developer is just so used to making a synchronous method call without ever taking the time to think about what will happen if it doesn’t come back -- it’s the Zen of the sound of a single hand clapping…

Have a look at the WebClient or WebHttpRequest class and see. There is no way to synchronously download content. You can write code with LINQ and inline delegates or Lambdas that “looks like” it’s synchronous, but it isn’t. You can try to use ManualResetEvents and other threading primitives to “trick” Silverlight into faking a sync method call – but none of it will work. Of course, the majority of developers having 3 or even 5 years of experience with .NET have never even written an asynchronous method call -- and now they’ll have no choice but to learn how. And that -- is a good thing. Silverlight needs to be truly cross-browser. In order to do that, it must implement the standard NPAPI plug-in architecture, which dictates that ONLY async methods can be used. At least -- for now. Work with what you've got - don't flame.

Thanks to the Silverlight dev team for doing developers a big favor. I’m for “doing it in the callback”.

About Me

I am a former Microsoft C# .NET MVP (Most Valuable Professional) for 10 years , author, and UnEducator based in the Orlando Florida area. I write mostly about .NET, formerly for eggheadcafe and currently at my programming blog at peterbromberg.net. I'm an ex-jazz musician and stockbroker who dreams of being a philanthropist and paying less in taxes. I believe in the US Constitution and free-market "Austrian" economic theories. I'm also a "climate realist" and believe in good science, which is never "settled".

As a computer programmer with over 25 years of hands-on experience in designing and developing large-scale enterprise applications, I am an expert at solving business problems.

I'm on Google+ because I enjoy engaging with others. Unlike Facebook or Twitter, the G+ ecosystem makes this much easier.

I'm a long time Mensa member, but I do not believe that possessing a high IQ makes you smart. My favorite quotation is: "Wrong is Right" -- Thelonius Monk.

I tend to be skeptical of everything, and believe that is a healthy way to approach ideas.

Some subjects that I am interested in are: Art, Jazz, Classical, Photography, Politics, Science, Erotica, Psychology,Economics. One of my hobbies is creating digital photocollage with my original photographs and Autodesk Maya software.

Most all of my posts are public, and I only have two circles: Close Friends (I get notifications) and Friends (Everybody else). You graduate to "Close Friends" when you engage with me and I see that we have some things in common. I am very accessible, but get to know me first by interacting with me before you send me a Hangout request.

NOTE: I occasionally make controversial posts or comments in order to stir debate. This rubs some people the wrong way. That's too bad. My comments are my own, and do not represent in any way those of any employer or client, past or present.

Excerpts provided by me are pursuant to the Fair Use Doctrine for educational and discussion purposes per Title 17 U.S.C. Section 107, Copyright Law.

Copyright Disclaimer Under Section 107 of the Copyright Act 1976, allowance is made for "fair use" for purposes such as criticism, comment, news reporting, teaching, scholarship, and research. Fair use is a use permitted by copyright statute that might otherwise be infringing. Non-profit, educational or personal use tips the balance in favor of fair use.