Fugato

Sales blurb for the HTC P3600 mobile phone:

„Process applications faster and store more data with 256MB internal ROM …“

Consolidated supply of music picked by project.ioni.st, that discriminating bastion of good taste:

project.ioni.st.m3u

(Yes, this will stay up-to-date.)

A brief feature comparison: in mid-flight I am impertinent enough to want to diff my checked-out code to see the changes I have made.

Under (the free-of-charge and open-source) Subversion, that would have been “Sure, here you go.”

Under (the $3,000 proprietary) Team Foundation Server, it is “be thankful I’m letting you work at all. And when you get online, go download a separate utility and ask it politely to sort out which files you have changed.”

And here I was trying to break the rant habit. Dagnabbit!

There are two rules of paramount importance in engineering innovation.

1. never reinvent the wheel.
2. always break the rules.

So I guess this was only a matter of time. Presenting: TheWheel™.

When you hear from software people (e.g. from yourself) things like “I don’t have time” or “it’s too much work”, there is a single-word slapdown response.

Ayende.

2.07 posts a day on average over the last three years, mostly high-value software stuff. At the same time, he spews out useful, robust software. That’s all on top of his day job. And apparently he reads a lot.

Personally I suspect Ayende is a five-person software company masquerading as a single person. Even then he is not doing too badly.

The obvious question: how does he do this?

The useful question: why aren’t you doing it?

(Ouch.)

In·shaʾ·Allah·tion (ĭn’shä-lä’shən)

n.

A software installation/upgrade performed as a leap of faith in the irrational hope that it might make things less terrible.

[From Arabic in šaʾ Allāh (إن شاء الله), “God willing”]

On our experimental TeamCity build machine, a build was failing in Release configuration (but not in Debug configuration) with the message:

"sgen.exe" exited with code 1.

The same project was building just fine on developer machines.

Googling the failure message turned up some pages suggesting a sledgehammer fix: disable “Generate Serialization Assembly” in the project file. But disabling something that may be valuable seems a little drastic just to appease a finicky build machine.

A better approach starts (as it always does) with getting more information about the failure. In TeamCity’s “All messages” view:

- This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem. (Exception from HRESULT: 0x800736B1)

If you would like more help, please type "sgen /?".
"sgen.exe" exited with code 1.

This yields the eminently googleable HRESULT 0×800736B1, which led to a couple of pages pinpointing the problem:

• the project references a DLL that depends on the C++ runtime library
• sgen.exe needs to load referenced DLLs
• loading a C++ DLL causes it to load the C++ runtime
• The C++ runtime exists on my machine because it has Visual Studio installed; the build machine doesn’t.

Solution: install vcredist_x86. The build is now fine.

I’m quite excited about TeamCity; go check out their early access program!

Suddenly my MSBuild fails because somebody deleted Reference.cs and there’s only a Reference.map in the Web References\LT folder.

So I try changing the reference’s URL Behavior from Dynamic to Static (just to make any change, to see if Visual Studio regenerates Reference.cs). That yields the error dialog pictured here.

Pop quiz, hotshot: what is the difference between OK and Cancel in this dialog?

None, apparently. I click OK and the property does change to Static. When I repeat the experiment, this time clicking Cancel, the property also changes to Static. Don’t know what else might be happening behind this error dialog …

… and that’s exactly the point. Where, pray tell, should I go to troubleshoot this error?

Well, silly, I’m a tech guy. I should figure it out for myself, rather than expect my tools to make it easy to find. Which brings me to my next question …

… how much did we pay for this IDE again?

Try calling this with a null argument.

public double AndCastYeHimIntoAnInt(object o)
{
    return (int) (o ?? 0);
}

It works as you would expect; returns 0.0 (implicitly cast from the integer 0).

But we like our casts explicit, so now try this:

public double AndCastYeHimIntoADouble(object o)
{
    return (double) (o ?? 0);
}

Woe is me; this fails with an InvalidCastException saying “Specified cast is not valid.”

But heavens, surely the integer zero can be cast to a double? For verily, (double)0 works just fine, and a debugger verifies that that (o ?? 0) indeed evaluates to the integer 0.

But put a watch on (double) (o ?? 0) and quoth the debugger: “Cannot unbox 'o ?? 0' as a 'double'”.

And lo, lift up now thine eyes and place a watch on (o ?? 0).GetType() and it shall prove to be the struct type System.Int32, a boxed integer, and that cannot be cast to a double.

It is a boxed integer unto the LORD, because the compile-time type of the expression must be object, the only type to which both object and int have an implicit conversion.

But why does a boxed integer not convert to Judaism double in the obvious way, by unboxing to int and then implicitly converting to double? Probably because supporting that would require extra work at runtime for every unboxing conversion.

With few exceptions, value-type boxing can be ignored. This is one of those exceptions.

I reported the Winforms Designer issue as a bug on Microsoft Connect. They swiftly marked it resolved “by design.”

What’s by design, exactly? Here are the actual and expected results from my bug report:

Actual Results

A dialog box saying “Specified cast is not valid” with an OK button, displayed three times, and then information lost about control instances within the form.

Expected Results

A clear, specific indication of the invalid typecast problem encountered while saving the form. And minimal information loss when the form is saved anyway.

So it is “by design” that instead of a clear, specific indication of the problem, we get a dialog box with only the exception message, and not even a mention that this message is coming from our own code? Just a quick and cheap MessageBox.Show(ex.Message) and their work is done?

Here is Microsoft’s exact response:

I’m afraid this is largely a byproduct of the way in which the windows forms designer works. It is setting the properties on a live object. If this object throws an exception, the designer has the choice of either letting the object throw (which would crash Visual Studio) or catching the exception. When it catches the exception, it displays the Message from the exception. The message you’re describing is the typical one for invalid cast. Hooking up a debugger will find what line the exception happens on, which would make it easy to see what the exact issue is (not just type information, but values, state, etc.)

UIFX Team

This misses the point completely.

I know full well that the designer works on live objects, and that bugs in controls therefore must cause problems. My complaint is about how those problems are handled, not that they come up. What’s “by design” is that they come up, sure. How they are handled is not “by design” (we should hope!) — it is a real usability issue that remains to be resolved. But Microsoft just shrugs it off, “you can attach a debugger to help find it.”

My point is that the exception they catch contains valuable information about the problem (the stack trace), and they do not give it to us.

Should we be grateful that at least we get a line number on compiler errors, without having to attach a debugger?

This product desperately needs competition.