Them’s fight’n woyds!

Expensify‘s CEO on “Why we don’t hire .NET programmers”:

Programming with .NET is like cooking in a McDonalds kitchen.  It is full of amazing tools that automate absolutely everything.  Just press the right button and follow the beeping lights, and you can churn out flawless 1.6 oz burgers faster than anybody else on the planet.
…

So what’s the moral of this whole story?  Two things:

1. If you ever want to work in a startup, avoid .NET.  It does you no favors.
2. If you are a startup looking to hire really excellent people, take notice of .NET on a resume, and ask why it’s there.

I recently knew of Expensify by reading this blog entry by Phil Windley. I can only guess from Mr. Barrett‘s conclusion that Expensify gets alot of resumes from .NET developers. From the employer’s perspective, following the law of averaging, it makes perfect sense. If your software platform is Linux, PHP and Bash, why would you hire a .NET developer? Rather, underlying the above two points is an implicit advice to startup employers—don’t use .NET technologies—which, I daresay, is ill-conceived. But hey, I’m not a CEO of a company. Not yet anyway. ;-)

In the end, probably nothing more than simply a publicity stunt.

What to do when CryptAcquireContext() fails

I’m using CryptoAPI to do encryption and encountering an error on Win2008 Terminal Server which enforces Mandatory Profiles. CryptAcquireContext() fails with a message of either “keyset not found” or “The profile for the user is a temporary profile”.

I’ve tried the same test on WinXP using a guest account and got the same thing.

So, what gives?

Well, this blog post (RSACryptoServiceProvider fails when used with mandatory profiles) way back in 2007 by @alejacma explains:

CryptAcquireContext will fail with NTE_TEMPORARY_PROFILE error when called from a mandatory profile.

Mandatory profiles are read-only user profiles. Since changes to the mandatory profile cannot be saved, PKI design doesn't allow this operation, and CryptAcquireContext prevents this scenario by failing.

The moral of this story is: RSA sucks, and I am now Rijndael’s new biggest fan.

By the way, troubleshooting this problem had given me the chance to learn a few more WinDbg commands:

.sympath srv*http://msdl.microsoft.com/downloads/symbols
.sympath+ c:\localsymbols
.reload –f
bm /a advapi32!CryptAcquireContext*

XmlSerializer and the "Specified" suffix

It took me 3 hours to figure out why XmlSerializer wasn’t writing out a particular class property. This is why:

…if a serializable Field/Property has a corresponding field of type Boolean having as a name the Field/Property name with "Specified" suffix, the XmlSerializer conditionally exclude that Field/Property from the serialization process.

DateTime Serialization to XML

I have an C# serializable object with a DateTime property like this:

        public class MyClass {
            public DateTime Date1 {get;set;}
        }

When serialized to XML, it gives me something like this

        <MyClass>
              <Date1>2010-11-30T00:00:00</Date1>
        </MyClass>

I could not get it to give me this, which is in the proper  xml date format:

        <MyClass>
              <Date1>2010-11-30</Date1>
        </MyClass>

After a couple of wasted days, it turned out that the solution is really simple:

        public class MyClass {
            [System.Xml.Serialization.XmlElement("Date1", DataType="date")]
            public DateTime Date1 {get;set;}
        }

Debugging hybrid VB6/C/C# app crashes with WinDbg

I was troubleshooting one of two (2) different app crashes this past week in which the app simply dies without any prior warning.  At first I thought: crappy VB6! But then, after looking in the Event Log, I found out this was not Visual Basic 6.0 Runtime’s fault, but rather it’s the .NET Runtime version 2.0 Fatal Execution Engine that erred fatally. Below is how I went about debugging the crash.

First of all, two sets of tools are needed:

1. Debugging Tools for Windows (WinDbg)
2. Debugging symbol (.pdb) files. These are useful but not essential.   PDB files are generated automatically in Visual Studio .NET, and can be turned on in VB6 IDE via the project properties under the Compile tab.

In using WinDbg to troubleshoot app crashes, I found this blog post Using WinDbg - Hunting Exceptions  by Johan Straarup to be tremendously helpful.

As anyone who’s ever involved in troubleshooting any software bug would know, the hardest part is to reproduce it in a consistent manner, and an app crash is (or should be) the rarest (and most feared by programmers) of bugs. Yet, an app crash is nothing more than an exception that has gone uncaught by the application.

In WinDbg, I used the Attach to a Process menu option to connect to the running app. Then, I issued the gn command (Go [until] Unhandled Exception) command, and let the app run its course.  Eventually, it came a stop with this message:

(4a4.1e4): CLR exception - code e0434f4d (!!! second chance !!!)
eax=0129ecfc ebx=0017d328 ecx=00000000 edx=00000025 esi=0129ed88 edi=e0434f4d
eip=7c812afb esp=0129ecf8 ebp=0129ed4c iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000202
…

I then used “!analyze –v” and subsequently “!pe”, which gave me this:

0:002> !PrintException
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscorwks.dll -
PDB symbol for mscorwks.dll not loaded
Exception object: 019138a0
Exception type: System.IO.FileLoadException
Message: Could not load file or assembly 'Interop.SHDocVw, Version=1.1.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
InnerException: <none>
StackTrace (generated):
    SP       IP       Function
    00000000 00000001 MyAssembly1.MyClass1.Finalize()

So, this crash was the result of a referenced assembly version mismatch in one of the plugin components. That's one easy problem solved.

The other crash is a bit more elusive, which, after two weeks, I'm still in the process of trying to reproduce.

Which config file to put the db connectionString for ADO.NET (3.5) Entity Data Model?

Normally this goes in the App.config. VS2008 designer wizard automatically creates this file and puts it in the same location as the  assembly in which your database layer resides. But if you’re calling that assembly from an ASP.NET app, you’ll  need to move that connectionString to the Web.config.  Otherwise, you’ll get this error upon  instantiation of the ObjectContext:

The specified named connection is either not found in the configuration, not intended to be used with the EntityClient provider, or not valid.

Using the .NET Framework Class Library from Visual Basic 6

I stumbled onto this link while reading another blog. Using .NET framework classes from VB6? Now that's just plain crazy talk!
Or is it?