carbon14 Blog

While unit testing my own functoids, I came across an odd scenario where my map was working with inline C#, but if I switched to testing the external assembly version, the results were completely different. Obviously I started with the assumption that my functoid was broken, but in fact it appears that it's Microsoft's LogicalAnd functoid which is broken, and has been since BizTalk 2006.

I must stress, that the failure only occurs when you are using the external assembly version of the functoid, which would occur only when you have set the script type preference on your map to give higher priority to the external assembly script type than the inline C# script type. And frankly I still don't know why you would ever want to do that. But if you do, the LogicalAnd functoid is broken.

In BizTalk 2004, the functoid used this code which works:

// Microsoft.BizTalk.BaseFunctoids.FunctoidScripts
public bool LogicalAnd(string val1, string val2)
{
	bool flag = false;
	try
	{
		flag = bool.Parse(val1);
	}
	catch (Exception)
	{
		if (BaseFunctoid.IsNumeric(val1))
		{
			int num = Convert.ToInt32(val1, CultureInfo.get_InvariantCulture());
			flag = (0 < num);
		}
		else
		{
			flag = false;
		}
	}
	if (flag)
	{
		try
		{
			bool flag2 = bool.Parse(val2);
			flag = (flag && flag2);
		}
		catch (Exception)
		{
			if (BaseFunctoid.IsNumeric(val2))
			{
				int num2 = Convert.ToInt32(val2, CultureInfo.get_InvariantCulture());
				bool flag3 = true;
				if (0 >= num2)
				{
					flag3 = false;
				}
				flag = (flag && flag3);
			}
			else
			{
				flag = false;
			}
		}
	}
	return flag;
}

but at some point, either in BizTalk 2006 or in 2006r2 they changed to this code:

// Microsoft.BizTalk.BaseFunctoids.FunctoidScripts
public bool LogicalAnd(string val1, string val2)
{
	bool flag = false;
	if (!bool.TryParse(val1, out flag))
	{
		if (BaseFunctoid.IsNumeric(val1))
		{
			int num = Convert.ToInt32(val1, CultureInfo.InvariantCulture);
			flag = (0 < num);
		}
		else
		{
			flag = false;
		}
	}
	if (flag)
	{
		bool flag2 = false;
		if (!bool.TryParse(val2, out flag2))
		{
			flag = (flag && flag2);
		}
		else if (BaseFunctoid.IsNumeric(val2))
		{
			int num2 = Convert.ToInt32(val2, CultureInfo.InvariantCulture);
			flag2 = true;
			if (0 >= num2)
			{
				flag2 = false;
			}
			flag = (flag && flag2);
		}
		else
		{
			flag = false;
		}
	}
	return flag;
}

The new code is cleaner, and uses the TryParse method of the Boolean, presumably to avoid the overhead of the try..catch block. But the sense of the second parse test is the wrong way round; that second exclamation mark shouldn't be there; and as a result this function will almost always return false.

The fact that this bug appears to have survived for a decade suggests that no-one ever chooses to prioritise external assemblies in their maps, but you never know.

A Boolean and function should be the easiest thing to get right, and it certainly shouldn't be difficult to have unit testing this function.

I've just had to help a friend with here broadband email service. It was working on Monday, but at some point during the week it stopped.

It was complaining that it couldn't get a response from the POP3 server. So I double checked all the documentation and rechecked the password. No good.

I had a look through her existing emails and discovered that she'd been sent details of a new email service that she was being moved onto. So I checked through the settings for that.
There were quite a few settings changes and I thought that would sort it, but no.

So then I went to the ISPs extremely slow, and badly organised AJAX enabled website, where eventually I managed to get the help pages to open for me. There I double checked all the settings, still OK and then looked for more help.

"Perhaps your password has become desynchronised in the move to the new service. Go to this page and change your password." It suggested.

I eventually had to find a different computer to get through the website without the AJAX choking and then I changed the password.

It still wasn't working.

I logged into the provider's site again, to be sure the password was right.
I logged into the provider's webmail service, which I discover is now a GMail solution.

There I find, in my friend's inbox, sent after the changeover, a new, and subtly different set of instructions on what to do to get POP3 working. Now you have to log into the webmail service and ENABLE POP3 apparently.

IF you move someone to a new email service.
AND some changes are necessary for them to continue to use it as before
sending them instructions AFTER the changeover is NOT GOOD ENOUGH!!!

Not content with giving their console a name that sounds very stupid in some languages, Nintendo's current advertising campaign gives the game away.

After shots of people using the controller to shoot and slash their way through mortal enemies, the voice over tells us...

Only ennui.

You can't make this stuff up.

The last two days I've been having trouble browsing the internet. My browser kept trying to connect to a mysterious 0.1.0.5 host.

Well that's obviously rubbish but I eventually tracked it down to a mysterious 3rd NIC that I seemed to have acquired as part of a Video Capture card installation.

No problem I thought, I'll just disable it and everything will be fine. But oh no, I can't disable that device, maybe it's not plug and play, or maybe a different user started it. That's ridiculous.

Eventually I got round it by giving the device a stupidly high metric, but what on earth is the point of such a device in the first place.