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....

http://msdn2.microsoft.com/en-us/library/ms364069(vs.80).aspx

Writing code that is fully interoperable with two different runtimes can blow; 'nuff said. The single-most valuable thing to remember when doing COM interop (in my opinion) is to add your damn .NET module to the GAC. Why?

The reason lies in the internals of COM, and if you've ever had the distinct pleasure of pounding your head against the desk while working on COM you'll quickly understand what I'm trying to say. COM was built with the ideals of interoperability in mind: so long as the two, distinct components stuck to a particular contract-based communcation (through "interfaces") then everything worked nicely.

In COM to get at a particular bit of functionality (which is exposed via an "interface") you must get at the Com Class (coclass) which implements the interface. A particular COM server houses the Com Class (coclass) which implements the interface. Basically, to get at functionality, then, you must locate the physical module, then ask the physical module to activate a particular "object" and then ask the "object" for an interface pointer to the functionality; the rest is done through vtable pointer arithmetic (this is all if you're using "IUnknown" semantics, otherwise the game is slighty different).

.NET interops with COM by having the mscorlib.dll module be the server - it is responsible for loading the necessary DLL files that implement your .NET functionality and doing all the proper dirty work of interoperating with COM. Say you have a COM plugin, then, for some application - but the plugin is written in VB.NET. The main application attempts attempts to create a com instance (through CoCreateInstance()) of your .NET module - this routes the COM runtime to Mscorlib.dll which attempts to locate your DLL; however, how does Mscorlib.dll find it? Well, if you haven't placed it directly next to (in the same directory as) the main application or in the GAC, MScorlib.dll will not be able to find your module and you're, effectively, "dot screwed".

....by placing the module in the GAC you'll be able to guarantee mscorlib.dll will find your module.

I am going to be published in MSDN this September on the internals of the ASP.NET AJAX ScriptManager control. For those that are currently reading this blog and have an interest in other subjects related to this topic, please feel free to comment and/or drop me a line (ben@sideshowsystems.com).

I've got another article in the works (another reason why blogging has been so sparse lately); but again no reason to believe it'll make it to MSDN again, but I'll try. I promise I'll try to post more regularly here too.

I'm a consultant, and as a consultant I spend a great deal of time concerning myself with the "next job". I may not always be a consultant (I don't believe it's related in any way shape or form to my eagerness to be one, just that times change, etc) but for the time being I am one and so must constantly be on the outlook for the next great "gig".

How do you go about getting a consulting job? Well, for me the challenge is my locality. I'm located in Nebraska which, for the most part, is a relatively barren wasteland for modern technology. Most of my "gigs" have been acquired through word of mouth and diligence on my part to help people in times of need when they requested it - you treat someone well and they'll treat you well back, it's the basic law of the land.

First - I would not look on sites like rentacoder.com. I have tried it, and I don't like it. Why? The reason is simple, for the most part people you will find on rentacoder (on both ends of the spectrum: developer or "buyer") are unrealistic. It's not their fault; they're not "stupid" in any way shape and or form, they're just somewhat naive about the nature of software and how much it costs to develop something correct. Take this for example: say you find someone on there who bids for a full-featured ASP.NET site for $20.00 (I've seen it); chances are they will be back bidding again in a month or two to correct the myriad of mistakes the $20.00 wunderkind caused.

Oh well.

Second - I would join local organizations, clubs, etc. and become active members of them and rub elbows with business-folk. One thing we, as developers, are relatively poor at is communicating with the outside world. You can make a business person fall in love with you if you express, in some way, an appreciation for their situation and, especially, a firm understanding of it. At the end of the day everyone is out for the same thing in business: to make money. Being an active member of this world will clue business people onto you as someone who "understands" the needs and processes of real-world business software. Remember, the stereotype most business dudes have of us is that we're cowboys - loose cannons who sleep by day and hack by night. For the most part they treat you as a risk - you wield a black magic that they do not understand; do not use this force for evil, use it for good.

Third - Do things with the end in mind. You have a choice as to whether you get yourself certified as a Microsoft developer or master your latest XBOX game. Look at your resume' and think about what it says about you - as a person. Does it project someone willing to explore the depths of a project for someone, or not?

Fourth - have a reachable presence. I'm not promising I'll be doing this consulting stuff in a year, but I am promising that as I continue to write, and continue to learn, I will continue to grow my presence/influence wherever and however I can.  This means things like blogging, speaking, writing for magazines, etc. The first step is always advertising your presence because without a presence you cannot be reached, period (well, duh).

Fifth - try your damndest to say atop of the needs of your area. Note how I say, "Of your area" - this is extraordinarily important. Areas differ on their needs and requirements for software; different places require different talents - you will succeed if you have a good rap sheet and expertise on those needs. Consider that and ask around, talk, discover, etc.

...I think the most important thing to take away is opening the lines of communciation, being accessible and being real. Believe it or not, but if you can make those things happen you can probably (probably) make it as a software consultant.

What if you had a web service method like this:

[WebMethod]
public List<String> Test() {
List<String> blah = new List<string>();
blah.Add("First");
blah.Add("Second");

return blah;
}

The method returns a generic List<> type of String objects. What happens if you want to consume it from AJAX via a web service method call like this?

function callWebService()
{
WebService.Test(OnMethodSucceeded,OnMethodFailed);
return;
}

The result will get sent back to the browser as an array type in JavaScript. Doing an alert() call on the result returned from OnMethodSucceeded like this:

function OnMethodSucceeded(result, eventArgs)
{
alert(result);
}

Yields the string "First,Second". You may also index into the array too and get the individual strings.

So, what about parameters? ECMA script doesn't support generics in the same way .NET does, but given that we've identified the runtime returns the generic list as an array back to ECMA script, it seems logical that we could pass a "generic list" to the runtime via ECMA script as an array. Indeed, we can. If we change the web service method to something like this:

[WebMethod]
public String Test(List<String> arg) {
if (arg.Count > 0)
return arg[0];
else
return "NA";
}

We can call it from script like this:

function callWebService()
{
var arr= new Array(5)
arr[0]="1";
arr[1]="2";
arr[2]="3";
arr[3]="4";
arr[4]="5";
WebService.Test(arr,OnMethodSucceeded,OnMethodFailed);
return;
}

The web service method returns, as a string, the first item in the array. OnMethodSucceeded, with our alert() method, will display "1" returned to the client.

My article has been written for MSDN now and so I'm back to blogging. The article wasn't done quite as well as I would have hoped because I've got about three or four other things going on at the same time right now and so focus has been thin; but it was an article and we'll see if it makes its way through the submission process.

Apart from that I have decided that I'm going to blog on the ASP.NET AJAX control toolkit for the next month or two, exploring each of the control's from the inside out and teaching people how to use them. Hopefully I can even contribute some of the things I write to the community project itself. Regardless, my hope is that we can all explore the internals of the AJAX controls a bit and begin to leverage them more productively.

I'll continue posting answers to people's questions too.

I'm going to go alphabetically through the control toolit, so starting tomorrow we'll begin an exploration of the Accordion control and I'll try to spend, at least, a couple days (maybe even a week) on each control.

Cheers.