...a variant is The type or namespace name 'MapPointService' does not exist in the class or namespace 'PointConversionCS' (are you missing an assembly reference).

If you download the MapPoint SDK from Microsoft, and try to run the samples, you'll get this compiler error. Basically remove all your web references and re-add them (same wsdl address) and then replace the following:

using PointConversionCS.MapPointService;

with....

using PointConversionCS.net.mappoint.staging;

and replace the following:

Imports PointConversionVB.MapPointService

with...

Imports PointConversionVB.net.mappoint.staging

   Try this sometime: open up MSN Messenger (the latest), and also open up Spy++ and try to spy, say, the text box you type into during conversations. What you'll find is that you can't, there is no 'textbox' registered with windows that you type into, and the same goes for the button you push when you want to send a message, there is no real button that exists there either; in fact, there is only one window registered with windows (that is, that has a valid window handle or HWND) in a messenger conversation window and its of type DirectUIHWND. I discovered this because I was trying to hook messages to some of the textboxes in the messenger conversation window manually, but was unable to since they didn't exist. All the windows that I would want to spy on are windowless controls, and they've been around a long, long time. Now, I forgot all about them, so I assume others may have too; the basic gist on windowless controls is:

1. They are windowless: meaning they have no handle registered with windows and therefore are not known to Windows and cannot receive messages.
2. They require the device context of their parent to actually draw themselves or, as is known in the ActiveX world, 'activate' themselves (that is, gain contextual information from the parent and start rendering themselves out).
3. They are COM objects and are activated on their container site; meaning there is a full-fledged parent/child relationship that exists between their container and themselves (they register themselves with the container, so the container is aware of them and vice versa).
4. They request the drawing surface or Device context (DC) of their parent and use that to draw themselves onto.
5. If they are activated upon a container that isn't aware of windowless controls, then they must register themselves with windows and become a fully fledge windows control.

   The parent (container) must implement IOleInPlaceSiteWindowless  and the windowless control itself must impement IOleInPlaceObjectWindowless for all the proper comunication between them to occur. So....what does all this mean? Well, for me it means it's going to be very difficult (near impossible) to hook messages meant for various child controls of the messenger conversation window (SUCK), for the rest of us it simply means a more effecient experience as windows aren't being created and destroyed using the infrastructure of the operating system itself, but instead using a light-weight mechanism internal to themselves. For more information, see this MSDN page.

....I found this via a google news link: http://www.mustek.com/ProductDetail.aspx?product=PVR-H140

   http://www.memorymanagement.org/

   This is a weird compiler error, but it simply means you're trying to assign a value to a method, and as you know, that's a no-no. Don't ask how I stumbled across this error
Recommended reading:

   And good ol' channel 9 has a video about the LINQ project (feature Anders Hejlsberg).

   I hadn't heard of this project before, but the concept seems quite cool. Back in the days of the 1.0 framework I had written a framework which allowed me to query metadata of objects on the managed heap of my process (I could search for strings, etc.); it seems as though I should have continued down that path, I guess...

I'm sure you're all aware of the WMF vulnerability and all the hoohaw surrounding it as a potential backdoor implanted by Microsoft. Mark, in his latest post (as of this posting) gives a wonderful analysis as to why he believes it's not a backdoor by Microsoft. What I find most interesting about this post, however, is the inside look given by him into the vulnerability itself; most of us simply download the patch by Microsoft for the 'bug' and call it a day - but it's interesting to look deep into why the vulnerability existed in the first place and how some 'flaws' may actually be, originally, simply a feature.