To Disambiguate or Not to Disambiguate.

Recently we got a Messageboard post from a regular at eggheadcafe.com asking what the XMLNS namespace declarations were for in his XSL stylesheet document. I fired back almost subliminally,
"To disambiguate..." Of course I know what it means, but a lot of people aren't sure. Just to see what's out there I googled the word and got 159,000 hits. The most common definitions and usage examples:

  • To establish a single grammatical or semantic interpretation for.

  • State unambiguously or remove ambiguities from. [this one is a no-no- dictionaries should never resort to using another form of the same word they are attempting to define! These guys actually did it twice in the same sentence. DOH!]

  • Namespaces disambiguate elements with the same name from each other by attaching different prefixes to names from different XML applications.

  • >No really, it's a word! It means to clarify a term.

Don't you gotta just love that last one. It actually comes from the Jargon Database, which coincidentally doesn't even have a definition for the root form, "ambiguous".


Boris - you got PLAN?

"Beh-heh! Of course I got PLAN! Dey don't ever vork, but I got one!"

Well, Boris, how about this: You want to deploy a .NET usercontrol app for which you have created a COM Callable wrapper (Register for COM Interop) and you want to deploy it via a web page in Internet Explorer with the typical CAB file codebase setup and an INF file in the CAB that says what to do.

Easy, right?

NOPE! Dig this from HOW TO (Q311297):

Components That Are Required by the COM Interop Program
  • The client computer must have the Microsoft .NET runtime installed before you deploy the COM Interop assembly.

  • Developers must deploy all .NET assemblies that are included in the program.

  • Developers must deploy all Interop assemblies that represent distinct COM that are included in the program.All COM components must be deployed and registered on the client computer.

Limitations of .NET Components Deployment
  • Developers cannot install assemblies from the Web directly into the Global Assembly Cache (GAC).

  • You cannot use the OBJECT element to start any already downloaded Windows Forms controls from the GAC.

  • You cannot deploy .NET assembly and COM component in the same .cab file.

  • A single .cab file can only contain one .NET assembly.

In short, about the only sensible solution to this is to refactor your solution so that all classes and namespaces are in a SINGLE ASSEMBLY!

The reason I bring this all up is because Morgan Skinner invented a very nice way of making a .NET UserControl fool the Registry into thinking its an ActiveX control:
-- unfortunately, because of the Internet Explorer partially trusted code sandbox, and the above nasty discoveries, it just about knocks that one in the head!

There are additional issue for developers to think about as well: When a normal call is made into unmanaged code from managed .NET code, a stack walk of all assemblies is performed to make sure that all of them have permission to make calls into unmanaged code. If you have an assembly that's been downloaded from the Internet, it is not going to have such permissions by default. And, I know of no way that you can give it such permissions.

Unmanaged code aside, you will need another MSI Installer (hey, its just the 23rd CAB file and OBJECT tag - what's the big deal!) that will set Full Trust on all your dependent assemblies, based on their being signed with a strong name. Otherwise, you'll have an ActiveX control, but it will be quadriplegic.

I read it, and I wept.

Boris! Don't vorry, Dollink! Vee don't need no steenking "Dot Net"! Squirrel and Moose can do dees weeth VeeBee 6, for only $12 hour! Plus, no benefits!

Gimme a break, guys.


VB.NOT again? Or VB.Fred?

It ain't a dead horse in my opinion, and I enjoy kicking it once in a while. The problem with VB.NET is really that we just didn't need a new language to complement C# for the .NET Platform. Listen, I started out with Applesoft BASIC, wrote some of my best stock analysis software in Turbo Basic, and was a Microsoft Beta Tester for the first version of the BASIC Compiler. I've made a lot of money as a classic Visual Basic Programmer with VB 5.0 and then VB 6.0. I've dabbled with JAVA, C++ and Delphi / Pascal. There's no question that its easy to write code in Visual Basic. Its also easy to write VERY BAD code in it.

I see it as a marketing decision. By all indications, at the time .NET was being developed, there were 10 times more VB programmers than C++ programmers. And people made the decision that they would provide all these VB crybabies with a VB-like language with a whole bunch of helper classes that would enable them to use these crutches to "migrate" to the .NET platform. They gave them a migration wizard which by almost anyone's account is - well, a joke. And they would even allow them to write code with Option Strict and Option Explicit turned off - BY DEFAULT! And that's where I draw the line.

Early on, at PDC 2000 in Orlando, when I brought home my 6 CD set of .NET Beta 1.0 I made a decision (as did many other VB developers)- I realized that no matter how "similar" VB.NET seemed to Visual Basic, it was not the same language. It was a completely different language. And then I found out that all 1 million or so lines of code in the ASP.NET runtime were written by Microsoft people in C#.

Have you ever seen something like this?:

Public Function TestMeOut(ByVal truefalse As Boolean) As Boolean
If truefalse Then
Return 1
Return -1
End If
End Function

-- Well, unfortunately, I have. Would you trust this code being called from C#? I hope not! Unfortunately as well, the above and a whole bunch of other similar crap will compile without a whimper with the default settings!

So, I started studying. And I decided that less words to type is better, and that curly braces and semicolons aren't so bad. And I'm glad.

Every time we get a forum post at eggheadcafe.com from some VB developer who doesn't type their variables or who doesn't enclose their code in try - catch blocks, it just reinforces my decision. There are so many crutches built into VB.NET that it's downright sad. Like, how many VB.NET programmers use DirectCast instead of CType? Have they even heard of it?

They've done a real disservice to VB developers, IMHO, by letting them "think" they can become professional OOP - oriented .NET Developers and continue to perpetuate the horrible coding habits they developed with classic VB and get away with it in .NET.

Richard Grimes, a gentleman who I respect and admire, says this in his parting DDJ piece:

"Some people regard VB.NET as wonderful. I really don't see the reason for the language. There are a few features that other languages do not have (exception filters and renaming interface methods are two), but these are not good enough reasons for a new language. There is the argument that VB developers would be more comfortable with VB.NET, but as I've said, VB.NET is not VB, and since a developer would have to learn principles of OOP and .NET principles like threading, exceptions, and delegates, the developer may as well learn a new language. C# is the natural language to use for .NET and there was no need for VB.NET. "

VB Fred would have been better. At least the name implies there's no relation to .NET from the dead language.

Scott Hanselman, who seems to have a penchant for the succint, put it this way:

Set VB6=nothing


What are the OBJECTS? That's the Question!

When you go to create software with OOP-oriented reusable "drop it in - plug it in" type objects, this question must be successfully answered before you begin. You don't need fancy UML diagrams. What you need to do is learn how to ask (and correctly answer) this question at every point in the development cycle.

If I am developing a VOIP application, for example, built from reusable objects of functionality, and I come to the part where i need to do audio capture and playback output (from the microphone and to the speaker), that's an object. Actually, its TWO objects. One for capture, one for playback. It shouldn't matter if I use DirectX, some Wave Audio ActiveX control with a C# wrapper, or even the WaveOut API - the functionality, the methods and the interface can all be exactly the same. What it SHOULD NOT HAVE is being tied in with RTP / SIP Packets, or IPEndpoints. Those are OTHER OBJECTS that have nothing to do with Audio capture / playback.

So the question should always be:



DirectX 9.0 February 2005 SDK Update Available

Get it here

( .http://www.microsoft.com/downloads/details.aspx?FamilyID=77960733-06e9-47ba-914a-844575031b81&displaylang=en&Hash=PKKGSD4 )


Vigilantes Attack Scam sites. Did they call in the Lone Ranger?

CNET Reports on Vigilante attacks on bank "419" scammers and the ISPs that host their sites. These are the scum who perpetrate fake bank deposit scams - you've undoubtedly gotten email from them.

The 419 Flash Mob is attempting to recruit as many people as possible to launch denial-of-service attacks on spammers' bandwidth and report them to their Web hosts and to legal authorities. The Web site provides contact details of computer crime units in seven countries.

Web sites with the following banks names are being attacked: Abbey Trust & Offshore Bank; First Global Trust; Allied Trust Bank UK (which is listed twice because two separate Web sites use this name); Crystal Bonds & Securities; Kash Bank Corp.; Liberty Stronghold Securities and Finance; and BBVA Finance & Clearinghouse.

I kinda like this type of Internet vigilante-ism. Kind of smacks of the Old West, where the Lone Ranger and Tonto had to take the law to the bad guys. Hell, I'd lend some of my bandwidth to see those bastards wiped out.


Submodules passed in the Ctor and Derived Properties

Recently a programming buddy and I were discussing various options for the population of various properties to a UI-oriented class from a generated Database - oriented class that "kind of" belongs with it. The idea was, he is generating the DB classes from stored procedures using a code - generator and it isn't feasible to change them around. However, he needed the flexibility to bring some or all of the properties in an instance of one of these DB - oriented classes into his UI-oriented class, allowing for the most flexibility without having to hard - code stuff or use reflection.

I suggested a possibility that I've used before: Pass an instance of the DB class into the Ctor of the UI class and store it in a private field there. Then, you can rig up the UI-class properties, fields or members in any way you want. This is far from a new idea - but our little exercise made me think how few times I've seen developers use this technique. Here's a simplistic illustration:

class MyUIClass

private MyDBClass _subModule;
public MyUIClass(MyDBClass subModule)

private string _myUIProperty;
public string MyUIProperty
return _myUIProperty;

_myUIProperty =this._subModule.WhateverPropertyOrExpression;
// ....


UNDUL Found! The Ultimate .NET Developer's Utility List!

I've run across this a couple of times before, but I never created a permanent link to it for convenience. Scott Hanselman, guru extraordinaire, has quite a comprehensive list of utilities that he recommends. Its so good, and so extensive, that I thought it would be a nice gesture to post a link to it here:

Scott Hanselman's Ultimate Developer and Power Users Tools List

Of course, there is a selfish method to my madness. Now that it's on my own blog, I'll never have to look for the link again.