Source: http://msdn.microsoft.com/msdnmag/issues/07/06/silverlight/default.aspx

 

1.       Introduction.

a.       Currently supports Mac OSX Safari and FireFox, Windows FireFox and IE

b.      Can be interacted with by AJAX code.

2.       Introducing Silverlight

a.       XAML is text-based and exposes it’s DOM to the browser in a scriptable manner (therefore, it is “functional”).

b.      The browser loads the XAML and creates a DOM that can be interacted with via script code, including modifications by script and event handling/processing.  You may also interact with the XAML DOM through methods (such as methods that start playing, stop playing or pause a presentation).

3.       XAML Overview

a.       XAML was first introduced as part of Windows Presentation Foundation; though the XAML used by Silverlight is a web-based subset of the full XAML supported by WPF.

b.      Silverlight XAML markup is based on the <canvas> tag; the “surface” upon which objects will be drawn.

4.       Inside the XAML

a.       There is support for pre-defined shapes, gradients, etc.

5.        Transformations, Media, and Animations

a.       XAML has built in support for transformations on objects (MatrixTransform, RotationTransform, ScaleTransform, etc).

b.      MediaElement tag controls video and audio.

c.       Animations are defined in XAML by how properties change with time.

6.       A simple silverlight application

a.       Currently silverlight.js is required to be located within the /js folder for your web application.

b.      Sys.Silverlight.createObjectEx() implements a new silverlight control.

c.       The silverlight plugin loads into a DIV tag with a unique ID.

d.      Dynamic features can be added to the Silverlight application (such as the source for a particular video) but modifying the script that controls and instantiates the objects through the ASPX page’s rendered output.

7.       Delivering XAML to the Silverlight Front-End

a.       The server can process and build the XAML as needed; the Sys.Silverlight.createObjectEx() method simply takes this markup to load and instantiate the XAML as a silverlight object.           

For those that deal in the world of asynchronous clientside programming, you've definitely encoutered JSON - the JavaScript Object Notation. The standard way of taking JSON formatted data and transforming it back into the javascript objects which it describes has been the eval() method. The problem, though, is that this is effectively invoking the JavaScript parser engine for the browser on potentially untrusted code - the javascript parser will basically execute whatever you give it through this method.

A relatively nice article (http://msdn2.microsoft.com/en-us/library/bb299886.aspx), it describes a script library located off of www.json.org (http://www.json.org/json.js) that provides a much more secure way of parsing JSON formatted data "parseJSON()". It's cousin "toJSONString()" is used to create the JSON strings.

...personally I haven't used this methodology, but it appears promising (at least until there is a much more standardized way of doing it).  

I've heard this question several times in the past few months and the answer is - an astounding - not even close. In fact, I would say that ASP.NET AJAX is going to enjoy a long and fruitfull life as a development tool for ASP.NET developers over the next three to five years at least, probably even more (though it may morph into something else during that time). However, this question - as to whether all the new client-side visual tools like Silverlight - is the end of ASP.NET AJAX is a fairly decent one given that, still, not a whole lot of people fully understand the depth of ASP.NET AJAX. Let's take a brief look.

First, ASP.NET AJAX is not only about AJAX; it's a full, complete, end-to-end framework for developers who wish to (or are forced to) dive into advanced client-side scripting. Quite literally thousands of controls are floating around in the world today that require the use of JavasScript - and millions upon millions of websites are leveraging it for reasons of client-side richness and control. What ASP.NET AJAX gives to the JavaScript (ECMA Script) developer is as close to an object-oriented, .NET'ish programming platform as you can get - so the need to write platform agnostic logic is either completely removed or mostly removed. For the millions of developers in the world right now who use JavaScript in their controls and web applications, development tools like Silverlight will not help.

Second, Silverlight is - like Flash - more of a user-interface platform all in itself. Like Flash, it will require the download of necessary bits to the client machine, and once there, will require a compliant browser to operate within. You will be able to create compelling interfaces, no doubt, but it's focus is always going to be angled towards the designer; the guys who think in the world of "flash'yness" (pardon the expression). A highly effecient, intuitive intranet or CRM solution, on the other hand, will probably not be written, ever, in a development framework like Flash or Silverlight - the same goes for an eCommerce webstore or a highly dynamic news site. These more business-oriented solutions will benefit greatly from the nature and flexibility of markup within the browser; and therefore find great benefit in the asynchronous attributes offered through ASP.NET AJAX. It would certainly be interesting if all the web pages out there looked like a high-end Silverlight presentation, but realistically, that wouldn't be practical at all to developer or maintain.

Third, ASP.NET AJAX is undergoing great advancements through the community - which shows a high focus on it as an important aspect of ASP.NET development. The open source community is contributing a great amount to the control toolkit, and this shows no sign of stopping or even slowing down.

And finally, and most importantly, Silverlight, Flash or what-have-you is not (nor probably ever will be) a natural environment to build products and solutions in for the ASP.NET, data-driven website developer. We have been raised under the notion of markup and are trained with that in mind, our websites are built around it, and the end-user expects it; the idea of removing or lessening the effects of this trend would be insane.

So, in summary, I see Silverlight being good for things like this:

• Kiosks,
  
• Company main or "splash" pages,
• Games,
  
• Presentations

...the kinds of sites where a designer would be involved mostly. And I see ASP.NET AJAX coming into play with:

• Intranets,
  
• Customer Portals,
  
• eCommerce sites
• Highly database backed or data-driven sites (like www.live.com)

...the kinds of things where a developer would be involved mostly.

Basically, there is no way ASP.NET AJAX is dead or nearing death. End of story.

Real buggy coding night. I'm in the process of putting together a site for myself when I ran into this problem:

http://forums.microsoft.com/msdn/showpost.aspx?postid=98346&siteid=1

Basically "Failed to generate user instance" and "An attempt to attach...failed".

For "An attempt to attach....failed" I was able to get around this by simply rebooting my development machine. Apparently there is some local cache of files stored on the hard drive that SQL Server Express uses and this was getting out of wack - somehow rebooting the system did the trick for me. It went away, but I was not able to identify exactly what caused the problem; to me this is a bad thing - I really like knowing WHAT happens when something goes wrong.

The "Failed to generate user instance" came from me being remoted into work from home (that'll teach me to work from home). Oh well, I guess I get my site done tomorrow.

Hrmph. :-(

We've all been pounded with "beware of SQL Injection Attacks" - yet I found a rather nice blog post here: http://blogs.msdn.com/dglover/archive/2005/06/01/423727.aspx that hands out a nice filter method for SQL Server. You might as well have a look and see if you can introduce it into your stored procedures....

Source: http://msdn.microsoft.com/msdnmag/issues/07/06/WickedCode/.

The main thing to take away from this article is that the UpdatePanel is a great control, but it definitely has its limitations when it comes to efficiency. Why? The article I linked to above does a fairly decent job of explaining why from a high level. The main, core, point to take away is that the UpdatePanel is good for purposes of simplicity; it will take whatever child controls are contained within it and make sure they participate in a partial post-back when one of them - or a control associated with the UpdatePanel - triggers a post-back event.

However, because the UpdatePanel must do so much for you it must believe that every control within it - or associated with it - could, potentially, need to be updated. These controls are mostly valid ASP.NET controls and, therefore, have ViewState that also must be maintained. In short, the UpdatePanel, in an attempt to be complete, will basically perform a pseudo full-postback to the server (even though the response message is optimized for use by the UpdatePanel). I guess, for a lack of a better analogy, think of the UpdatePanel as a mini page all to itself; I guess that somewhat holds up....

....so, bleh. If we're trying to be effecient, what do we do?

There are a couple options (one of which wasn't mentioned in the article but I would like to mention).

1. Utilize PageMethods. PageMethods are static methods of your ASP.NET page class that are treated as web service'able methods. You can reach those methods through your script and the PageMethods proxy class: yet another proxy class auto-generated by the ScriptManager and its bretheren.
   
2. Use a standard web service. If your ScriptManager has web services registered with it, it will auto-generate proxy classes for use when calling those methods from javascript. What this enables you to do is basically script against those methods.
   
3. And, the one that was left out - use the asynchronous scripting methods of ASP.NET AJAX:  http://ajax.asp.net/docs/ClientReference/Sys.Net/WebRequestClass/default.aspx

...being somewhat of a gearhead, I like the WebRequest class because it gives me absolute control over things; but it's definitely overkill for 99% of all uses (it's what Microsoft used to build the UpdatePanel and the asynchronous page-framework of ASP.NET AJAX). Basically MS "dogfooded" the WebRequest class for all async behavior in ASP.NET AJAX.

This last TechEd I went to a session on getting work as an independent consultant and ever since then I have been really focused on optimizing not only my own searching but that of other consultants. A couple more things I would like to mention:

1. If you have no problem getting certified for a security clearence, the government is hiring right now. People at the session really pushed the fact that the government is really looking into independent consulting at the moment (for one reason or another), and that it might be a good opportunity for independent developers.
2. Charity is, suprisingly, a good option. Even though you may not make a lot of money (or any) helping out a charity, charities have benefactors - people that donate money - and your good deeds go noticed. Benefactors do have money; doing a good job for something a rich person cares about might have its benefits.
3. Staffing agencies are there to help. Staffing agencies like this one: http://www.teksystems.com/Services/Staffing-Services/Default.aspx are there to link up parties. These people, obviously, take their cut, but it's a great way to get started. Remember - beggars can't be choosers.

...just a few more things to think about.

In my opinion, what seperates the "wo/men from the mice" in the world of software development is the tools. I have known some incredibly brilliant individuals who could wip out some of the cleanest, fastest algorithms I'd ever seen,  yet they were burned when it came time to develop real-world software because somebody with half their talent knew how to engage the debugger in the right fashion, or they knew how to use perfmon, etc. etc. etc. These days my mantra is "Resist the urge to overcomplicate your life", and if you're a developer, that often means getting to know your tools a bit better.

A few questions to ask yourself:

1. If you were developing a heavily multithreaded application in .NET (client-side) and it deadlocked on a test machine, would you kill the process and inspect the debug logs or would you attach a remote debugger to the process and identify exactly where the threads were hung?
   
2. If you had code that needed to be transferred from one developer to another (say you had a bit of source you wanted to share), would you email it to them as a copy-paste and leave it be from there, or would you instruct them how to use code-snippets in Visual Studio to better the source and share it with everyone else?
   
3. How many know how to use WinDBG? SOS (Son of Stike)?
   
4. Do you have debugging symbols enabled on your machine and those of your testers? Do you have a symbol server? Do you know what that is?
   
5. When was the last time you enabled tracing in your ASP.NET application to fix a performance issue? Did you immediately hit the source code or did you let the tools work for you?
   
6. FXCop?
7. Have you ever ran your application against perfmon? Have you ever used perfmon's remote machine feature?
   

The list goes on and on. The important thing to remember, though, is that at the end of the day you will have to fight with code that is insanely complicated, distributed and (often) not yours - if you try to fix/find/discover/analyze a code problem through code, you're probably looking at it from the wrong level; there are many, many great applications out there (for free or that come with Visual Studio) that will mitigate your problems and reduce the amount of time needed to identify bugs.

So, before you start your next task ask yourself if you're doing everything you can to not overcomplicate your life....