So this was the highlight of my day...
While installing the latest (2010) version of TaxWorks for a small accounting firm. I ran into (what became) a total fiasco because of an error message that was (quite frankly) completely
wrong. TaxWorks incidentally is owned by RedGear this year, and they were making a big to-do about how much they'd changed/improved/modified the install experience (all of which was pointless nonsense). So...
Server install went ok.
The first 5 client machines went ok.
Client number 6 went completely to shit.
The install went fine, but... ended with the first launch of the program, which launched an updater, which insisted on closing the program ... Which was the last time I saw the S.O.B. for a very long time...
I should probably mention here that TaxWorks is written in VB.NET
Post update, the program displayed a splash screen (for awhile), then gave a string of error messages. Here's some examples:
There is an error in XML document (x, x) during Deserialization. - With tons of other .NET framework verbage referencing System.String and a caption that said System.XML something.
Failed to load Path name. - Caption blank.
Error while XML deserialization
And my favorite, Can't load browse for database form error which was also replete with tons of .NET related malfunction info.
Now the damn thing is already running on 6 machines. all of which are pointed at the same database which worked perfectly. So the issue has to be with this machine. All of the error messages when googled point to something being coded wrong which doesn't fit with the other machines that run just fine. But it did seem to fit with the classic .NET meltdown scenario because all of the messages point to an issue reading a string from an XML file that doesn't have any errors in it ... That I can find.
So I do a repair of the .NET framework. No luck.
I completely strip .NET out of the machine, and reinstall it from scratch. No Luck.
I completely strip out the client software and .Net to be double damn sure I'm really starting from scratch. No luck.
I go on a bugg hunt (malware etc.)...No luck.
I try a bunch of other miscellaneous shit that I don't recall...because I don't even want to think about it.
I finally find (after much wild google-foo) a support article for TaxWorks (
SO10580 - Failed to load path name error) that mentions the offending error. It also mentions the offending XML file. Which is on the server...that all the other machines are using...So therefore it can't be broken (even tho the article insists it is). However...
Just for fun (lacking a clue what else to try) I popped the file open in notepad to take a look see. and it listed the Server local file path as D:\Taxprep\TY10. Hm... - Mind you I inherited this configuration with several previous years already installed so picking D: wasn't my idea I just had to go with what was there until the next server update.
Now this is a network install, the clients point to a network path, but the XML DB description file points to a server local path of D: - which was correct...for the server. All of the error messages implied that the Db path string could not be read. But the other machine worked with it just fine.
So just for the hell of it - being at my whits end... - I reach down and hit the eject button on the (as usual D: drive) CD-ROM ... and out pops a music CD. W,T,F?!?
The program now runs fine.
I reinsert the music CD and restart the program ... Which returns to failure mode.
Remove CD, restart program, it runs fine.
I continue to repeat said actions for about 15 minutes because I quite frankly refused to believe what I was seeing.
The
correct error message should have been:
A file IO error
A permissions error
Path X cannot be accessed
A database location X is inaccessible error
Something that gave the impression that the location given was unavailable.
The error message should have listed the path that could not be accessed...Not tell me that the path STRING or file it was in didn't exist/was corrupt. That is (not helpful) flat wrong.
Not to mention the obvious question: Why the hell is it enumerating local drives looking for a database that is specified as being located on the (very not local mapped drive) server which its already friggin connected to?
Yes for clarity it went through these steps:
Read DB location string from registry (correctly).
Accessed location specified.
Read XML DB description file (from the location specified) for Tax Return storage location (correctly).
Left the location it already was and was supposed to be in...
And then failed to find the specified network location on Local Machine.
Threw a bunch of errors that said the .NET string/XML handler had failed and/or the file it was already done reading was unreadable/corrupt.
This entire fiasco was caused by lazy programming that assumed that function X couldn't possibly fail so there was no reason to create an error message for it (and this is a top dollar commercial application).
Oops!
Incidentially, in the interest of (my version of) fairness, I did
not bill the client for the 2 hours of our collective time that this little nightmare wasted.
